I don't think this would work for SSH keys. From what I recall, sshd normally doesn't use pam, and even when it uses pam it's not usually used in the auth role, except for password ("keyboard-interactive") authentication. Authentication using SSH keys is performed separately of PAM, and then pam "session" modules are used to initialize the user session and check parameters. So what this results is (I think) that authing as ssh:firstname.lastname@example.org would let me auth via password, but not via SSH key, unless I had a home directory on the server with my key in it.
I could be wrong, there might be a way to do this via pam with a module which doesn't actually check the PW and only provides homedir / user id information, but from reading the pam spec I'm not sure this is possible. One other possible approach would be to replace openssh with something like twisted.conch ( http://twistedmatrix.com/trac/wiki/TwistedConch ) which does have pluggable authorizers and you could integrate it readily. I'm not sure what performance would be like with bitbucket's load, but it's certainly an interesting prospect.
You'd need to run openssh on a different IP/port if you use it for normal SSH login to that server though.
Thanks for your input! Unfortunately, I think you're right about OpenSSH not ever handing key stuff over to the PAMs, and handles that internally.
I thought about using Conch, but as you said, with our load, I don't know what kind of performance I can squeeze out of that, and for that, it might not be worth it just for letting people use their own usernames.
There's also the question of user naming policy and whether it'd work as a valid SSH username. Or heck, I have usernames both "Crast" (which I don't use) and "crast". I have no idea what'd happen there.