It may be useful for you to separate the libraries of third-party node.js servers (via npm, etc.) from all libraries and browsers on the client side (such as jquery, backbone, knockout, etc.) when you think about it. Even socket.io, which provides a permanent socket connection between the browser and the server (to avoid polling), does not determine which client-side technologies you use.
Focus on exhibiting a reliable web api ( random example ) from your server, and your client technologies can be replaced, supplemented, etc. without affecting the server. The only place where they intersect is to use viewing technology such as Jade. It is also an opportunity to have a clean separation, where the server simply serves the client files, and your client is a thicker javascript application (using knockout, jquery, etc.) that invokes a good server website.
Some people try to combine client and server models — for example, this article using backbone and node. It depends on how much data you work to say if this is possible, but it connects the client and server and makes it server-side, which may have flaws (scaling, affinity is required, etc.). Personally, I am wary of this magic (binding, state, synchronization, etc.). Node is to keep things simple, light and fast. It is a fast network server.
My 2 cents (and some may not agree). Start with Node on the server and select your repository (mongoDb, etc.). The design of a solid RESTful (hypermedia) API is a good webapi, regardless of the client. Then start with the basic html / css / js, possibly a jquery client, and add things like knockout, etc. when you expand your customer experience. This will allow you to replace your client technologies regardless of your server, as new technology winds change (and they will).
This is the hallmark of a well-designed system - the ability to replace components / subsystems without rewriting everything :)
Hope that helps clear up the fog :)