This only requires the user not to read the URL and match it to the URL in the Google Authenticator app (as far as I can see right now).
If you use U2F, then the domain name difference will mean that the U2F key can never match unless the attacker has control over DNS and is issued a Google.com SSL certificate by an authority the target's computer trusts.
Your browser connects to [email protected] but no matter whether you believe that site to be Google, the U2F process means that it can only use a key for phish.me, which won't work on the Google.com servers even if they relay it.
The only attack which still works is if they control DNS and can forge an SSL certificate, at which point we have much bigger problems than phishing.
Or if they're able to get some malware onto your system permitting them to change your dns servers or alter your hosts file, and add certificates to your OS/browser trust store.
And in the long run I have more faith in making systems more secure via technological means than to try and convince users not to click on links in shady email messages. So by moving the problem into the technology domain and out of the social domain, I'd say it's a big win.
With U2F, however, a per-host keypair is generated during the setup process and the public key is given to the remote server. Critically, the hostname as seen by your browser is part of the key identifier: see http://security.stackexchange.com/a/71704/311
That means that if in the future even if someone convinces you to visit their phishing site and activate the token, the login attempt will still fail because the hostname as seen by the browser won't match a key on the token.