It may not be the most secure method, but it’s certainly the easiest way to deliver some keylogger protection without doing major changes in the backend code. The methods you mentioned are not “standard” as a virtual keyboard (which many people have already seen in banks), how much of code refactor will it really need to be safety implemented?
This is fairly trivial stuff – for some definition of trivial (like yes there’s work, but it’s not like building a whole new application, it’s augmentation of the authentication workflow). Effectively we’re just talking about a functional transform on bytes, strictly speaking there’s no reason the password needs to anything more than a normalized byte sequence (this is all math behind the scenes).
Even “real” passwords are fed through a key expansion algorithm for AES (and pretty much any other serious encryption algorithm). This would just be a preprocessing step based on some secondary data.
Figuring out how to generate the secondary data is the hard part. Rot13 isn’t a super practical example as it’s very local to US style keyboards, the English Alphabet, and Arabic Numerals. It’s also fixed so any attack on Bitwarden could just reverse the trivial transform.
I’m sure it’s this difficulty that’s (understandably) slowed any kind of progress on this. I mena, you could simplify this idea down to a dropdown that says “Pick your favorite color”. That would then select a different algorithm behind the scenes based on the colors, and potentially tied to the account. That would explode every garbage password by N*X “color/user” combinations.
Such an approach could make even “Password1” a difficult to crack password if Bitwarden’s servers were to have a leak, because “Password1” was “salted” another time with an unknown (okay, known to be in a set “N”) secondary secret, protect against software and hardware keyloggers (though not if the software keylogger could also screengrab), and just generally be a pain in the butt for an attacker.
The complexity introduced would be storing the selection of algorithms for a particular user, adding a dropdown, and then adding the algorithm to the JS library… This is basic “development” work, modulo picking the algorithms to use to modify the password.
Really… You could just use one key, and have this be a user selectable salt that gets mixed in with the password salt. So the “real” password for purposes of authenticating against a hash is “UserInput”.“User Salt”.“User Selected Salt”. Then you apply the same concept to the AES key extension (I’m assuming “User Salt” doesn’t play a role in this though I don’t know Bitwardens Crypto code – this is kind of “abstract”), and effectively “salts” the password input and decryption key.
Password1.Blue in effect becomes “Password1.<Bitwarden Stored Salt Correspoinding to User XXX’s Blue>”.
EDIT: The more I think about it if I ever decide to go back for a PhD this would be a really interesting space to explore 
A virtual keyboard would be only a matter of frontend design and some basic JavaScript
This is not trivial stuff. There’s a lot of complexity in making a virtual keyboard. I guess you could just “list keys” as buttons, and have a picker for keyboard “layout” that picks those keys. Then you’ve got to figure out how to make that all pretty.
Most people I’d argue are not concerned about defending from hardware keyloggers. Software keyloggers are the bigger issue. It’s bad enough to have a machine compromised, if it’s been compromised at a hardware level, that’s an entirely different extreme.‘’
EDIT: Also if your concern is a hardware based keylogger… Just use your operating system’s onscreen keyboard.