i'm not sure how these guys did it, but one could do a similar setup. one of the issues to overcome is availability of ports. since most apps will listen on port 80, you can use the HTTP Host header to virtual host instances. a reverse proxy can be set up at nnn.jsapp.us, look up the nnn and get an IP:port of which (internal) node instance to pass the request to. you could internally use UNIX domain sockets so there wouldn't be a need to worry about TCP sockets, but your frontend proxy needs to be smart about this.
thus nnn.jsapp.us can be mapped to a single IP address. things get more tricky if you allow people to host arbitrary TCP servers that aren't reverse-proxy friendly. the jsapp.us implementation seems to ignore a port argument to listen(), which seems reasonable.
the jsapp.us implementation seems to be able to keep multiple node instances running. obviously, if more and more people start hitting the server with their apps, this could lead to resource starvation. they probably have a clever way of not keeping the node instances sitting idle. if a particular nnn.jsapp.us host exists and the node instance isn't up, start it on the first "cold" request to that host. this allows the service to keep only those instances up and running that have had recent requests. or maybe they shut down a user's instances only when they log out or close the editor page?
that's my take on it. someone (maybe the jsapp.us guys?) should put together an all-in-one node.js hosting service that has a nice web-based editor based on Bespin or Cloud9 IDE and integrates node-inspector for an awesome remote debugging experience.