You're kind of fighting against the natural tendencies of how source IP address selection works when trying to do this. So why not just change your design up a little bit for it to flow more naturally?
The problem is that source IP address selection is done prior to the decision to push traffic down the tunnel. That means that it'll choose to use the "public" IP address as the source IP for any traffic originating through the tunnel.
On some OS:es, you can do fun things with routing, specifying source addresses on a route for host-originated traffic. I can't find anything like that on Windows though.
However, given your network design, I think the simplest way of solving this problem is to stop fighting with RFC1918 addresses on the server side, and just go ahead and set up a tunnel with SA's between your public ip 203.10.10.10 and the private IP addresses 10.16.0.0/15.
The clients would then address the server as 203.10.10.10 rather than 192.168.70.1, and everything else would hopefully just magically fall into place. That way, source IP selection will already pick an appropriate address that will work.
You can keep the old ipsec policy in place during a transition period, so that your clients may address the server either with the old RFC1918 address or with the new public address, while your DNS cache expires (assuming you're using DNS for this - if not, it's a good idea). After a transition period, the address 192.168.70.1 has no function any more.
The other option is to explicitly choose the source IP address when initiating connections from your server - which may be possible if it's custom software you've written yourself, but that's kinda hairy.
Finally, that loopback adapter idea is promising, it's odd that it shows up as "media disconnected" though. That sounds like a problem with the loopback adapter itself rather than with the idea though.
Best Answer
If I have understood correctly I believe a combination of Reverse Route Injection and OSPF redistribution with do what you are after.
Reverse Route Injection dynamically creates static routes for you VPN tunnels.
Redistribution will advertise the static routes via OSPF (or other routing protocols)
I am currently doing this way