Your on the right track with the UI being part of the problem.
We should never give anyone our password, including the site were connecting to or our own computers which could have maleware.
Instead passwords should be stored encrypted on a personal secure device with say a USB connector, whos software and hardware have been well audited, with a touch screen keypad for entering passwords.
It could work in this way. With your browser you make a SSL connection to the site, the site challenges you, your browser sends the site's public key and challenge over encrypted connection to your secure device. Upon receiving the challenge, your device asks you if you would like to connect to site with this public key, on behalf of browser xyz with session id xyz, where browser is previously authenticated, and session id is a random id displayed by your browser. Then it asks you to enter the password/pin/fingerprint, or whatever security you have setup on your secure device. However before sending out its challenge response, the secure device sends its own challenge to the site, asking for confirmation that the site is really the same site you originally setup the password for. After getting the challenge response from the site, and verifying the site, the secure device sends the challenge response to the browser, and the browser forwards that response to the site, and then use of the site can go forward.
This has a number advantages:
1) You never gave our your password to anyone, but instead a key is generated based on the public key of the site you are connecting to, and a random key generated by your secure device, and the generated key is encrypted to the site itself, so that only the site can see this.
2) Additonal authentication over the existing signed certificate scheme is done. This does not protect the first time connection, but does protect additional connections made, which gives you a lot more protection in that all aspects of a given site must be compromised for you to get spoofed, in otherwords the site's private key, trusted cert, and the key you share.
If for whatever reason you lose your secure device or it is compromised there will need to be a way to invalidate your accounts, and so that will require some kind of group of trusted 3rd parties such as bank, email, or whatever you choose. This might be another set of passwords, background questions, etc. but this is not something you are going to do every day.
Also for additonal security, it would be nice for servers to be able to quickly see if a secure device has been compromised by auditing with the trusted 3rd parties when it is able to do so. The site could take the first quick measure of suspending an account, and then require the much more careful measure of reestablishing an account to its full capability.
For first time connection to a site, there would have to be additional security measures, and that is where a 3rd party (or group of 3rd parties) make sense to help in that establishment of trust. Where your secure device could force authentication of a site with 3rd parties, and the site could force authentication of your secure device with 3rd parties, before you agree that you are both trust worthy.
Might as well tie this secure device to credit cards as well, in that your secure device becomes your credit card.
Perhaps what I just described could be better implemented in a new SSL like protocol using the secure device as a proxy setup by your browser.
This would require an overhaul of websites, browsers, and so on, but it is about time we develop and industry standard for solving this nagging problem.