Q:

How dangerous is it to translate IPs directly via hosts in Windows

Sorry for the inconvenience, as English is not my native.
I use hosts to access some websites as DNS is polluted.
My question is, take www.google.com as an example.
If I am successfully social engineered by an attacker, and changes the translation in hosts into a phishing website.
If I use http, then I am completely screwed, right?
If I use https, then the browser will give a warning, if my PC is not compromised.
For the https case, is it possible that the phishing website just pass a certificate from www.google.com to me to prove it is genuine?

A:

Consider the following statements:

All certificate authorities trusted by your web browser refuse to issue a certificate for examplebank.com to the attacker without proof of domain ownership.
The signing keys of all authorities are securely stored and an unauthorized person cannot issue a certificate to themselves. (See recent Comodo break-in.)
Your web browser correctly checks if the server's SSL certificate is issued by a valid CA, not revoked, valid for use by servers, and issued for the examplebank.com domain.
There is no active malware or a browser bug that causes such checks to be bypassed.
You always open https://examplebank.com, requesting SSL explicitly instead of relying for the website to redirect you.
You actually read the SSL error messages instead of blindly clicking Ignore when you open the website.

If all of the above are true, HTTPS will warn you that you tried to connect to a fake website. However, HTTPS cannot bypass lower-level redirections (such as spoofing examplebank.com by DNS or /etc/hosts), so if you ignore the warnings, your data will be going to the attacker, not to the real bank.
To conclude, yes, it's dangerous.

In response to the edited question:

If you use plain HTTP, you're screwed.
If you use HTTPS, you will receive a big red warning (see first part of the answer).
Every "certificate" has a RSA (sometimes DSA, ECDSA) key pair. The public key of the pair is part of the certificate, while the private key is locked away in the webserver and never sent over the network. Both keys are needed to successfully complete the TLS/SSL handshake.
If the attacker presents a certificate, but does not have the associated private key, they will not be able to decrypt any traffic that goes over TLS. Wikipedia has a description of the TLS handshake.

A:

SSL (HTTPS) will only protect you as long as your client is not compromised.
If someone manages to modify /etc/hosts, he can also manage to modify your browser to not perform the SSL validation of the server you're connecting to, or he can add his fraud server's fake certificate into your system's database of trusted certificates.
If however your client is not compromised and someone manages to redirect your browser to a different IP address (e.g. some kind of DNS-related hack, or cheating you to modify /etc/hosts without anything else), the browser will warn you that something's wrong with the server's certificate, and, provided you don't ignore the warning and proceed, you are safe.
On your second question:

For the https case, is it possible that the phishing website just pass
  a certificate from www.google.com to me to prove it is genuine?

No, that is not possible, unless the attacker managed to obtain the server's private key (e.g. by hacking the server itself). Even if a fraud server "passed on" the server's certificate, he will not be able to prove its identity to the client if it does not possess that private key. If he attempted to do that, he will fail and the browser will show a warning.

