Some people will say no public DNS records should ever disclose private IP addresses....with the thinking being that you are giving potential attackers a leg up on some information that might be required to exploit private systems.
Personally, I think that obfuscation is a poor form of security, especially when we are talking about IP addresses because in general they are easy to guess anyway, so I don't see this as a realistic security compromise.
The bigger consideration here is making sure your public users don't pickup this DNS record as part of the normal public services of your hosted application. ie: External DNS lookups somehow start resolving to an address they can't get to.
Aside from that, I see no fundamental reason why putting private address A records into the public space is a problem....especially when you have no alternate DNS server to host them on.
If you do decide to put this record into the public DNS space, you might consider creating a separate zone on the same server to hold all the "private" records. This will make it clearer that they are intended to be private....however for just one A record, I probably wouldn't bother.
You have made huge changes to your question and completely dropped the EC2 aspect of it, but here's my new response:
I think you need to learn a bit more how DNS works and how virtual hosts work. DNS is used to turn a hostname into an IP address (or set of IP addresses). Once an application has an IP address to talk to DNS is no longer involved.
Virtual hosts is a feature enabled by the HTTP protocol (version 1.1 and up). When contacting the IP address, the client passes in the hostname they want to make the request of. Your proxy server would need to be set up to understand HTTP and map to different back end servers.
Most other IP protocols do not have this feature so there is no way to do what you ask. E.g., there is no hostname involved after the DNS lookup when you ssh to a server.
That said, it sounds like you have a particular problem to solve. Rather than assume IP address routing is the answer, how about asking about what you are trying to do at a higher level and see what folks come up with? I'd recommend starting that in a new question.
I leave below my original responses to what appeared to be your original set of questions...
What you are trying to do is not clear from the wording of your question. Here are some answers to possible questions:
It is not possible to "conserve IP addresses" on Amazon EC2. Each instance uses one public IP address whether or not you allow it to be accessed from the Internet.
EC2 already has private DNS names for the private IP addresses, but they are no more useful to use than the private IP addresses themselves.
You are welcome to run your own DNS server inside or outside EC2. There are some DNS serving software packages that support code plugins where you dynamically determine the resulting IP address based on algorithms.
If you resolve an EC2 instance public DNS name from an EC2 host, Amazon will return the private IP address so your networking will be faster and cheaper. For more information on this feature, see this article I wrote:
Using Elastic IP to Identify Internal Instances on Amazon EC2
http://alestic.com/2009/06/ec2-elastic-ip-internal
Best Answer
Your main issue is this: You have a router/firewall out in front of your mobile device. Unless you have some way of accessing that ISP/phone company router to enable port forwarding, you'll never be able to access the webserver externally. Even if you hook up something like No-IP or DynDNS to your webserver so that the external IP address of the ISP/phone company is correct, without port forwarding those requests will just hit the firewall and stop.
Bottom line - your ISP/phone company would have to approve of this plan and let you do it or it's going to fail miserably...
EDIT As mailq points out in a comment - you need data pushing, not data pulling - you're almost certainly seeing your competitors pushing data automatically from the sensors to a central server. That's pretty easy to accomplish. Pulling data from behind the 3G NAT routing is dependent entirely on your 3G carrier participating with you.