There's definitely some mechanisms in place to help you out here.
For internal LAN traffic, between systems on your network, there's Unique Local Addresses. Think of them like RFC1918 addresses; they'll only work within your network. You'll be able to use these addresses for any communication within your network borders; just carve off some nets from fd00::/8 and have your routers start advertising them.
In a normal deployment, this will mean that your nodes all possess (at least) 3 IPv6 addresses; a link-local fe80::/64 address (which can only talk to other nodes on its broadcast domain), a unique local fd00::/8 address (which can talk to everything in your LAN), and a public address.
Now, this still means you're renumbering everything when you change ISPs (which you're doing now anyway for publicly addressable nodes assuming you don't own IPv4 space), just that you don't need to worry about all of the internal communication, which can stay on the Unique Local range.
That might cover your concerns - but there's also the NPTv6 proposal, for which there is currently an experimental RFC. This would allow you to translate the public prefixes to the private ranges at the network edge, meaning no renumbering internally when you change ISPs, and the ability to utilize multiple ISPs with disparate assigned addresses seamlessly (either permanently or during a transition period for a provider change).
As said in the first comment, I also strongly suggest moving to dual-stack, since, in the long run, it is cheaper than implementing NAT solutions. (You will have to do it anyway, so why not now?)
But still, for your problem, there are two possible solutions/workarounds:
- a router with NAT64 support;
- a load balancer with native IPv6 support, balancing servers behind it via IPv4.
Best Answer
DNAT
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:
Downside: Clients with firewall might not be allowed to connect to port 81.
Proxy
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
to answer incoming requests from clients on the sites which resolve to the v4 addresses site[123].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.
HTTPS
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.