This is not really feasible with passwords. This is feasible with any scheme where the key/secret/credential/token/whatever is stored on a client's computer and not inside human's brain.
Convoluted? Turn exactly the same thing around: if you have a sufficiently random and sufficiently complicated key/secret/credential/token/whatever, it doesn't even make sense to ask a human for a username, a nickname, a GUID, any other identification for an everyday authentication. Software will tell them all these.
If your software doesn't welcome suckpuppet accounts that is. (Some do welcome. For example ssh is happy with "sockpuppets", different accounts used by one human; it asks for account name even if you provide an RSA key. Sockpuppet RSA private keys sitting one next to another on the same device would be unnecessary complication, not more security.) Asking for a nickname is the easiest way to support sockpuppets.
"Sufficiently complicated" key implies we don't ever expect a collision. It implies we don't ever expect a need to salt it. It implies average human cannot remember it. And it implies we don't need the additional bits of complexity from human remembering the username.
The only problem is reset after losing the key or after it is compromised. It means a lost or compromised device. Here we need to use a more secure authentication (also possibly a more troublesome one). Do you need user to remember their nickname here? If you ask user only for a mother's maiden surname, the collision is near-certain. That doesn't mean you need a nickname, it means surname authentication is too weak! All the attacks would be about the poor mothers' maiden names. But you will likely need to ask for some global outside-of-the-app identifier, most likely a mobile number for SMS verification (this excludes the threat of attacker controlling your mobile).
Alternative scheme is e-mail verification, also requiring a global outside-of-the-app identifier (this excludes the threat of attacker controlling any your device, so it's really weak in this setting).
Observe that, in most cases humans don't need to remember their global identifier, but sometimes they do need to go check it up and enter it manually.
Alternative scheme is pre-shared paper verification: ask user for a one-time password number 04 from the paper card mailed to them when they opened an account. It is one case when I find it handy to augment with a "trivial secret" authentication, so that just about any person who obtains a letter doesn't reset access just for fun or out of sheer curiosity. It could be "what postal code did we use to mail this paper?", it could be the dreaded maiden name, but it could as well use a nickname.
Passwords remembered by humans
The password, or a short secret text that could be remembered by a human, is an inferior scheme that is long overdue. The associated unnecessary costs include:
- "please login" page
- "this nickname is occupied" problem
- "this password is too weak" problem
- need for a server-side salt (upgrading the weak secret to a truly random one to counter rainbow tables)
- KeePass and similar databases - overcomplicated solution to a simple problem of getting a proper scheme to work over old login prompts
These all vanish with machine-stored key scheme (symmetric or asymmetric, the latter suggested) .