The answer depends upon what kind of browser you are using, so I'll break it down.
Mobile browsers. You can't trust anything you see. Sorry. Life on a small screen sucks. That's just the way it is.
(Did you want an explanation why? Any web page can go full-screen, using mobile-specific tricks like scrolling the page down so that the address bar is not showing. Then, it can draw a fake address bar. As a user, there is no reasonable method you can use to detect this forgery by looking at the screen. See also the research paper iPhish: Phishing Vulnerabilities on Consumer Electronics, where the authors implemented this attack and tried it out; they learned that users could not detect it, not even computer science graduate students with knowledge of security, not even when they had been warned in advance of phishing attacks.)
So basically, there is no reliable way to detect phishing attacks on mobile browsers by looking at the screen. The only way to protect yourself is to go straight to the site yourself (e.g., by clicking on a bookmark) before entering your credentials: never get there via a link.
Older desktop browsers. On older browsers, like IE6 or Firefox 2, I don't know whether there is anything you can trust. They are so riddled with security holes that I would not count on them for security. The only way to protect yourself is to simply avoid those browsers: friends don't let friends use IE6. But you said you are not interested in them, so I think we can disregard them.
Modern desktop browsers. This is the nub of the issue, and I suspect what you were most interested in. On modern desktop browsers, there are only a few things you can trust:
Domain name. You can trust the domain name in the address bar to indicate the site you are currently on.
Blue/green glow. You can trust the blue/green glow behind the name in the address bar to indicate the presence of SSL. You can also trust the `https://`` schema to indicate the use of SSL, but the glow may be easier to check for.
That's essentially it. You can not trust the icon next to the URL (the favicon), even if it looks like a padlock or something; you cannot trust anything below the address bar; you cannot trust the text in the status bar when you hover over a link before clicking on it. You should not rely upon anything in the URL after the domain name, as the same-origin policy makes no distinction between different URLs on the same domain.
How to protect yourself. Let's put it all together. If you want to be safe when visiting some site -- say, your bank -- there are two viable strategies you can use to protect yourself:
Prevention: use a bookmark. To prepare, make a bookmark to the login page for your bank. (Make sure it is a https page you are bookmarking.) Then, when you want to log in, click on the bookmark, then enter in your credentials and use the site. Never navigate to your bank's site by clicking on links; if you find yourself on your bank's site from some other source, then make sure you're on the right page by clicking on the bookmark before you use the site. This essentially prevents any opportunity for a phishing attack on your bank credentials.
Detection: check the address bar. Alternatively, you can try to detect phishing attacks. Every time you visit your bank web site, check to make sure that the domain name in the address bar matches your bank's domain name before entering your credentials or using the site. This will be a pretty reliable way to detect phishing attacks -- as long as you always remember to check the address bar. The primary shortcoming of the approach is the obvious one: you have to always remember to check the address bar. Apart from that caution, this is a viable strategy, too.
Also, you may want to check that you are currently using SSL, by checking for the blue/green glow (this is especially important when using a wireless network); if you happen to know that your bank has had a green glow in the past, then on subsequent visits make sure the glow is still green. Alternatively, if you use Firefox, you could install HTTPS Everywhere and save yourself from having to check for SSL.
Caveats and attacks. I need to qualify the above remarks a bit. Checking the address bar is not a foolproof defense. There are some sophisticated presentation attacks that could potentially fool you, even if you look at the address bar. Let me outline the major ones:
Picture-in-picture attacks. Recall that a web page can completely control what pixels are drawn on the portion of the browser window where it is displayed (e.g., by providing a bitmap image, which will be displayed exactly as is). In a picture-in-picture attack, a malicious web page arranges to draw something inside its window, so visually it looks like there a second, smaller browser window has popped up on top (and its outline is completely contained within the outer window). This is hard to describe in words, so here is an example image:
Credits: Fig.2 of An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Barth.
In this example, the user is visiting a malicious web page:
http://paypal.login.com, as shown in the outermost address bar. The malicious page controls the contents of all the pixels inside this outer window (except for the chrome around the border). In this area, the attacker has drawn an image that replicates the appearance of a second smaller browser window, popped up on top. Since the attacker controls all of the pixels of that image, the attacker can completely control the "address bar" of the "inner window". The attacker has chosen to spoof an "address bar" containing
https://www.paypal.com. If you weren't careful, you might conclude that the inner "window" has focus, look at its address bar, conclude you are talking to Paypal, and enter your Paypal password or other personal details into the inner "window". If you do that, you've actually revealed your Paypal password to the attacker.
For more on this attack, read An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Bart. I'm only aware of one instance of this sort of attack in the wild.
Homograph attacks. See "The Homograph Attack" by Gabrilovich and Gontmakher, and "The methodology and an application to fight against unicode attacks" by Fu, Deng, Wenyin, and Little.
Full-screen attacks. (TBD)
To my knowledge, these attacks are rarely (if ever) seen in practice, and they might have only a partial chance of fooling users, but I wanted to outline them so you are aware of the ways in which browser security is not perfect.