The first question's easy: yes, that's exactly what NAT is for, but you'll have to put your single v4 address in front of your v6 server pool, give each pool member an RFC1918 v4 address, and punch one real v4 address/port pair through to each RFC1918 address/port pair that you want to have v4-addressable. You would need to manually assign an external port to each server:
- port 81 => server1:80
- port 82 => server2:80
Downside: Clients with firewall might not be allowed to connect to port 81.
If you don't want to do that, the v4 box will need to run some kind of virtual host proxy, so that it can receive requests from v4-only hosts for service on the v6 pool, proxy the requests through, and serve the replies.
A how-to for proxy setup is way beyond the scope of an SF answer, but essentially the front-end box needs to maintain a proxy table something like
- site1.example.com/* proxy-> [2001:ea48:abc1:3500::1:1]:80/*
- site2.example.com/* proxy-> [2001:ea48:abc1:3500::2:1]:80/*
- site3.example.com/* proxy-> [2001:ea48:abc1:3500::6:1]:80/*
to answer incoming requests from clients on the sites which resolve to the v4 addresses site.example.com, and proxy them out to the servers running similarly-named sites on the v6 addresses listed above. The proxy will also need to return the responses to the requestor. For v6-enabled clients, you can advertise the proxies themselves under their AAAA records, if you also get the routing and v6 firewalling right.
As for HTTPS, the situation is identical to those wanting to run multiple HTTPS servers natively on a single v4 address: you can either run multiple v4 ports (punched through; see above), or rely on SNI (see lots of places) and ignore hosts that don't support it.
I suspect that what you're really asking is "is there magic server-side pixie dust that can enable v6 connectivity for end-users who are v6-unaware", and I think the answer to that is "no". You'll have to accept their requests entirely in v4, and get the answers back to them the same way; see above.