Although I can't point to any specific reported defects, I'd be nervous about the node.js architecture - where your code runs as part of the webserver code. While with something like mod_php, there is still only a single process handling both the HTTP and logic tiers, there is a clear functional separation between the 2, and the interface between the webserver and the logic tier has been expressly designed and tested to accomodate failures - particulary in the logic tier.
Also, there are a lot of tools available for webservers (Apache in particular) which facilitate management and (used properly) enhance security.
Another major consideration is availability of skills/support/training - regardless of its quality / utility, node.js has a lot of catching up to do compared with other web development platforms.
Our development team has been considering using Node.js
That you are specifically trying to deliver what should be a very secure application on a platform which (judging from your statement above) you are not thoroughly familiar with seems to be very reckless. Most security vulnerabilities in web applications arise not because of faults in the development environment but in faults in the bespoke code added on top.
Certainly using a reverse proxy would facilitate getting standard HTTP logging, anomoly detection and reduce impact of protocol level attacks.
One of the best tools for building secure web applications is mod_security - AFAIK, this is only available to run within Apache - but it would offer the possibility (along with mod_proxy) of deploying a front-end system providing the usual webserver functionality (logging, static content) along with, say, authentication services, and using node.js as a backend.
Six long years and nobody has ventured a response. Well, I've got a bit of hindsight to complement experience so I'll proffer one.
Q1. Maybe. If you don't mind adding the complexity of cluster to your app, and you're careful to avoid anything that might throw in the master process, then cluster works great. Otherwise, you certainly want something to handle supervising your node process and restarting it when your app crashes. Your OS might provide alternatives such as daemon or systemd.
Q2. No. At best, on a good day with the wind at its back, node-http-proxy is almost as good as nginx or haproxy. Excluding SSL where both haproxy and nginx are much better. It'd be awfully hard to build a case for it being more suitable.
Q3. Yes, or haproxy. Until you have the need to introduce varnish. When you get to that point, you won't have to wonder if you should be using varnish. (Or you'll use a CDN).
Q4. Your call. Haproxy is my default tool of choice for TLS termination and proxying. I don't hate myself enough to put something as critical as a load balancer on someone else's server where I can't run tcpdump or other troubleshooting tools.
Yes. If you known nginx well, then use it to handle the HTTPS termination and proxying the requests to your app servers. If you aren't heavily into nginx already, consider haproxy instead. With a name like haproxy, you'd expect it to be really really good at HA and proxying and it doesn't disappoint.
haproxy / nginx. Always. Better certificate management, listing at cipherli.st, etc. There's also less impact to your app to upgrade the proxy when openssl vulnerabilities are released.
haproxy. (nginx supports proxying websockets now, so this question is past it's expiration date).
Multiple sites and BGP. Introducing tools like keepalived or other peer-to-peer TCP failover mechanisms to your stack is just as likely to be the cause of an outage as to prevent one. The use of such tools is typically rare so the human with site knowledge of it is out of practice when the necessity arises. Keep the stack simpler and depend on the skills of your network team. They are well practiced at routing around problems.
Best Answer
It is unlikely you'll ever see Node.js in a shared environment, because your Node.js processes run as long running processes rather than being instantiated via CGI or anything like mod_whatever under Apache.
This means you are looking at a dedicated server or VPS and even then you'll be at the top end of your budget. Something like Linode's smallest offering might be the best value you'll find with that budget - you can get cheaper, but you don't want to reduce your specification much further than that.
You might get away with less RAM, perhaps as little as 256 MB, but you are likely end up swapping so the I/O bottleneck of sharing drives with other VPSs will kill you then. You do sometimes see cheap old dedicated servers (lowish spec P4, 256 MB RAM, small drive) for US$25/month or even US$20/month - keep an eye on the offers area of places like WHT or more specific places like OLM's server-a-day if that is what you want.
The Node.js framework itself doesn't need much RAM or CPU power per instance due to its evented rather than threaded or process based architecture, but what sort of specification you will need will very much depend on what your code is doing (what sort of data processing?, how large are the data sets?, what database work?, how many concurrent users/processes are you expecting?, ...) so we'd need much more detail to be able to give you much of a more specific answer. Though with a maximum budget of US$25 it might be a case of taking what you can get and finding a way to live with it!
Edit: (2013-01-10)
Since writing that answer, prices/capabilities have changed quite a bit as you'd expect. There are in fact a few places offering Node.js hosting, and there are some very good standard prices on VMs (Linode is still a good recommendation IMO, but there are better value offers if you want to take the risk of a less well known provider) and small dedicated servers (from the likes of kimsufi.co.uk for instance).
But don't take hosting recommendations from relatively static pages like an Server Fault question without further research on discussion groups specific to hosting: the market changes so much that any answer here quickly becomes out of date, which is why shopping questions are generally discouraged.