The important word in that sentence is "directly". There are plenty of ways to do I/O in node, but they generally involve event-based callbacks so that they don't block the thread.
Are there any special considerations for keeping the TCP connection open while the thread is waiting for the callback? I'm assuming no, since node.js doesn't seem to exist in order to facilitate long running requests.
I'm not sure, but I'd guess closing over it in the callback would work, as long as the TCP timeout is longer than the database response (even then, you could probably touch the stream every so often while you wait, perhaps via nextTick or something).
I don't really have a direct answer to your question, but the somewhat official demo for node.js is a chat server that uses http long polling to push messages out, so node can definitely handle that.
Node is designed specifically TO facilitate long-running requests. There is only one thread (it's a single-threaded, evented system). Everything is done with callbacks, so if you have a long running I/O operation you'll just add a callback which completes the current HTTP response when the long-running I/O has finished. Node is quite happy to keep thousands of such callbacks around at once for massive concurrency.
Since Node scripts are persistent (i.e. aren't created and destroyed for each request), it doesn't care how long or how many connections are open. It's ideal for long-running requests.