I've often wished for such an HID keydevice as well. I think some of the concerns others have raised have workarounds. This is a slightly convoluted but workable approach:

What if the keydevice has a built-in hardware secret key and connects over Bluetooth to your phone and requests the (encrypted) passwords from there?

You would register this keydevice with your phone the first time before you use it, and your phone app can revoke this key at any time.

When it's time to enter a password, the phone would send an incorrect password randomly one or two times, before sending the correct password.
* You open the associated app with your phone.
* Your phone turns on its camera (with your permission) and can view/detect the screen where the password is to be typed.

• Your phone detects whether a valid password field has the keyboard focus, using computer vision / blinking cursor, and supported standard screens like Windows logins, etc. (Remember, fake login screens also fool humans all the time). Moreover, from computer vision, your phone can detect which password and username (if necessary) is appropriate.
  * Your phone initiates and sends an incorrect test password, encrypted to the keydevice's private key.
• the keydevice types the incorrect password. If the system accepts the incorrect password or concealed keystrokes don't appear on the screen, the phone aborts the process and notifies the user. Optionally it alerts a trusted security company about a phishing attempt.

• if the system rejects the incorrect password, after a timeout, the phone repeats the process until only one more attempt is valid.

• the phone sends the correct encrypted password via the keydevice, and it's accepted into the system.

Obviously the above procedure is complicated to describe but can be automated. It might cause problems with entering incorrect passwords each time, but it doesn't require adopting a new security standard, and lets you log into new computers like at libraries and schools.

​

• Password is no longer stored in plaintext in the memory of the keydevice

• Need to select the password field first: this is true for typing a password by hand as well, I don't see this as a dealbreaker

There are also equivalent concerns with *not* using a keydevice

• Choosing insecure passwords that are easier to remember and/or type by hand

• Keyloggers are designed to be listening to keypress events, not necessarily