Take away the 'authentication' part and just talk about the encryption part please! (Authentication is a different problem.)
Example: a connection to http://ipv6.google.com can be encrypted via HTTPS like this: https://ipv6.google.com/ (If you don't have IPv6 you can try IPv4: https://www.google.com)
Is it possible to program webservers as well as browsers to support e.g.
http-over-ipsec://ipv6.google.com
as better and more secure replacement for https?
The problem with encryption is not the protocol (be it SSL, TLS or IPSec) but the bootstrapping. SSL and TLS rely on trusted (for a certain value of 'trusted') third parties who certify that a certain encryption key belongs to a certain website. Otherwise how would we know if we are really talking to the right server? The connection might be hijacked. Authentication is always important (always for the client authenticating the server, and sometimes also the server authenticating the client). Without authentication anyone can claim to be ipv6.google.com.
With the growing DNSSEC support we get better bootstrapping options: DANE (RFC 6698) and IPSec keys in DNS (RFC 4025). Both of them make it possible to use the DNS (which has to be made secure with DNSSEC) to bootstrap the encryption. The DNS tells the client about the certificate that will be used, and we don't have to rely on third parties anymore.
Make sure that DNSSEC becomes widely deployed and this becomes possible. Otherwise we will be stuck with the current complicated and expensive system of third party certificate authorities...
No, IPsec cannot and will not replace HTTPS because they are effectively Apples and Oranges, here's why:
IPsec operates at the network layer and is negotiated explicitly via IKE - both endpoints have to agree on a keying scheme, mode of operation and a number of other parameters which are then installed into whatever is responsible for the IP(v6) stack (typically the kernel of the operating system).
*IPsec is designed for protecting an entire channel (or channels) of communication over a prolonged period as opposed to simply setting up a brief session, exchanging data and tearing it down.
Hence, IPsec simply does not scale well for the sort of lifetimes that HTTPS typically experiences (i.e. repetitive, short-lived connections), not to mention the fact that it explicitly relies on the IP stack itself makes implementing it within the application both problematic and a security issue, since configuration of IPsec parameters are generally a privileged operation requiring root/administrator access.
HTTPS on the other hand, more specifically, SSL/TLS operates on the basis of the application (such as your web browser) having a pre-defined list of authorities that it trusts to sign server encryption certificates.
As mentioned in another answer, whilst DNSSEC could very well be used to bootstrap IPsec, This is already perfectly doable for TLS and indeed has been codified within the IETF as RFC6698.
