The problem you are trying to solve is that the client needs to be identified by the server (to know which user this is) but the server needs also be reliably identified by the client to detect phishing. I agree that simply using HTTPS for identification of the server is not enough, since an attacker might simply own a similar looking domain (e.g. paipal.com vs. paypal.com) and get a certificate for it and thus can also do HTTPS.
The usual process of identifying the client by the server involves some kind of shared secret, where the client sends this secret to the server and the server verifies it (i.e. logging in with password). This process is obviously vulnerable to phishing.
The existing answers on this questions thus offer ways to make the user at least detect the phishing by having a second shared secret which is then presented by the server and verified by the user, i.e. use the customers phone number or some user chosen image as the second secret. But this second secret is not enough too because once the attacker successfully phished the user to get the initial secret (the password) (s)he might be able to determine the second secret after logging in.
Thus the proposed user chosen image alone is not enough because the attacker can find out the secret and reuse it. Only the SMS based proposal solves this problem by not showing the second secret to the client (and thus to the logged in attacker). Instead it only uses the secret indirectly to generate yet another (third) secret (a token) and make this secret known to the user in a way which is hopefully not accessible by the attacker. The client must present this secret token to the server and thus prove knowledge of the secret. Of course you could also use a different channel like e-mail or chat or an actual (automated) phone call to transmit the third secret, as long as the channel itself is not accessible by the attacker.
But while the proposal with the second channel sounds nice it has the problem, that it depends on this second channel for security. If this channel gets compromised by the attacker (i.e. trojan at the smart phone intercepting SMS) the security is broken. And if this channel gets unavailable (like with a lost or stolen phone) no login is possible and thus also no change of the secure channel. Historically this is a weak point and often attackers got access to the site by calling the support and tricking the support person into changing the phone number or e-mail to an attacker-controlled one, of course after answering some security questions where the answers could often be easily found out.
Apart from that none of these solutions deal with the problem when the attacker makes its own phishing site (e.g. paipal.com) and simply initially relays all data to the original site (e.g. paypal.com) and after successful authorization then cuts off the original clients and uses the established session for the attackers purpose. Simple HTTPS will not help here too because the attacker might get a certificate for its phishing site too.
An alternative way to secure the communication is to use HTTPS together with client certificates. Using the underlying public key cryptography the client can be identified by the server and the server by the client. The attacker might still create a phishing site but cannot capture the secret (i.e. the private key of the clients certificate) needed for later reuse. Because it is often not that obvious for the client that a client certificate is involved so some kind of phishing detection is still needed, but in this case the presentation of the user-chosen image could be enough. And since the attacker is not able to use the real client certificate to identify itself against the original site it can neither determine the user-chosen image nor is the relaying attack described above possible. Unfortunately the process of using client certificates is mostly not that user-friendly and also the certificate must be included in every browser the client uses. Also the certificate is shared between all users of the browser profile which might be a problem too if multiple users use the same computer.
