It's not actually useless. For one thing, it's possible to design a protocol where any MITM attack can be detected after the fact. tcpcrypt creates session ids in the course of setting up the encryption, with the property that they will match if and only if there was no MITM. Thus clients could conceivably store the session keys and compare them later over an authenticated channel.
Additionally, you could design the encryption protocol so that the initial stages are indistinguishable from an encryption-with-authentication protocol. Using tcpcrypt again as an example, you can layer auth on top of it by just setting up encryption as usual and then sending the server's session id to the client, signed with the server's certified public key. Then the attacker has to decide whether to try a MITM attack before knowing whether it has any chance of working. If he tries it and it turns out there is auth, he's detected, guaranteed.
So it's not true that encryption without authentication is useless. It does nothing against an ideal attacker, so it gives no guarantees. But it can make it a lot easier to detect attackers who are careless, and can make it harder for even careful attackers to pull off indiscriminate attacks with no risk of detection.
But I'm not sure it would be any easier to get such an encryption scheme working in browsers than to fix HTTPS so every site can use it. If we had SNI support and DNSSEC stapling support in all browsers of consequence, and DNSSEC were readily available for all domains, then good tools could conceivably make HTTPS about as easy to set up and maintain as a hypothetical HTTPE.