OK, but bcrypt works! As far as anyone knows, the best you can do is just brute-force it, which is the same situation we're in with public key cryptography. The only substantiative difference is that passwords are often of a length and complexity that actually permits brute force or a dictionary attack -- meaning we're back to, is it small and memorizable, or a big binary blob, as being the distinguishing property.

You're assuming that the web sites use bcrypt. From the perspective of a web user, public/private keys allow me to not trust the web sites.

That's true, you don't share a private key with an authenticator, so it's unlike a password in that sense - but it's still what-you-know authentication, and any what-you-know authentication that a user can't actually know/remember is impractical.

Given the current infrastructure, yes, it's impractical.

But a correct infrastructure could be easier to use and an order of magnitude more secure.

And it wouldn't have to be rolled out all at once. I really wish my bank gave me the option of signing in with a private key today.

A private key (or client cert) is generally more of a "something you have" than a "something you know" credential.

(unless you memorized your key - it's something you have, not something you know)

Well, it's data. I guess it does reduce to "what you have" given that it's not memorable, but as we all know, "what you have" is less convenient than "what you know".

What if your iphone/android device helped you manage your private key?

A website could send a push-notification to your phone. You as a user would then have to say "Yes Its me logging in" and voila your in.