You can split the problem to simplify solutions.

For simple phishing take two steps: 1) require that all automatic password transactions take place over an SSL connection (easy), and 2) have a user interaction to add any new hosts to a white list. This second step also flags spoofing attempts, so the whitelist message needs to both warn and educate the user. If it really is a new legitimate host for password storage, save the certificate information and proceed. If you get the warning for an old site you need to investigate before proceeding.

I would compare and display the certificate information about the organization. Organizations change infrequently, and the user is more likely to be aware of these changes. Also do a partial match search and flag likely spoofing attempts (e.g., homotypes).

Then there is the issue of the untrustworthy local machine. This is fundamentally hard to solve and need not be solved. Accept that you need a trustworthy local machine for important transactions, but minimize what you need on it. For my corporate access the trustworthy local machine is my ID fob. All it does is generate one-time use, time limited passwords. I enter a PIN into it, and it shows me the password on an LCD. It limits my exposure to a few minutes and is a trustworthy source. This is not perfect. For example, an attacker could piggyback an unauthorized transaction along with an authorized transaction. But this would have to be over the same SSL connection, so it calls for a much more extensive local penetration than a simple password sniffer.

For many purposes an SMS capable cell phone is an acceptable trustworthy local machine. The programmable ones are even better. You can use a standard algorithm, the accurate time inherent in cell phones, account specific seeds (delivered by SMS or physical mail), and an account PIN to generate the one time use, time limited password. This is easily within the capability of a cell phone. The function can be bundled in with the rest of the address book functions so that it is a minor variation on dialing a number from the cell phone address book.

Second, demand bi-directional mutual authentication for some transactions. This is very inconvenient if done wrong. But for some transactions it is worthwhile. The cell phone companies take advantage of the SMS messaging for some of their products. As part of account setup they know your cell phone. So they send a portion of the transaction over SMS, or demand that you send a token or passphrase via SMS. By splitting the transaction over these two paths you force the attacker to penetrate both the computer and the cell phone. This is immensely harder than implementing a password sniffer or transaction piggy back.

For example, suppose the transaction confirmation displays a transaction ID confirmation (say 10 digits). You are required to SMS that transaction ID plus a PIN to the account confirmation number within 5 minutes. The transaction does not complete until the confirmation is received, and then you get the final confirmation by computer. This is annoying and might cost a few cents for the SMS message, so you only do it for transactions with significant value. Even if the attacker is watching all this, they will not be able to generate the SMS with the proper return number unless they have also cloned your cell phone and stolen your transaction PIN.

Another variation is generation of one time use credit card numbers, requested and delivered by SMS. They might be vulnerable to highly specialized piggyback attacks, but you are not vulnerable to other losses due to exposure of the credit card.

This doesn't deal with integrated browser/cellphone, but it does reduce the problem space.