If the user connects to
eve-mail.com, Eve will be able to inspect any data sent to it, as the TLS connection is terminated at
eve-mail.com, of course.
Whether Eve chooses to reverse proxy the user requests to Alice or not simply depends on whether Eve wants to keep up the illusion; it isn't really relevant beyond this.
Can this be prevented? It depends. The user connects to
eve-mail.com, so content served from
eve-mail.com will be trusted. OTP 2FA doesn't really help either as
eve-mail.com could just proxy the OTP.
However, there are some defenses.
If you are using a YubiKey or similar alternative as a second factor, the device would use origin-bound keys to prevent phishing as described. From the FIDO U2F spec:
When the user registers the U2F device at an account at a particular origin (such as http://www.company.com) the device creates a new key pair usable only at that origin and gives the origin the public key to associate with the account. When the user authenticates (i.e., logs in) to the origin, in addition to username and password, the origin (in this case, http://www.company.com) can check whether the user has the U2F device by verifying a signature created by the device.
As long as you initially registered with
alice-mail.com, you're protected by origin-bound keys.
In the absence of a security key, services could block login on confirmation via a second channel. Both Apple and Google prompt for login confirmation via second factors, and the login confirmation prompt traditionally displays both the IP and/or the associated location of the login request. A savvy user might notice that the location does not match up with their own location, or that the IP does not match up with their own IP, and deny the login request, reset their password, etc.