Need some help splitting up my Node.js code

Instead of writing comments, I would avoid using anonymous functions or meaningless names.

For instance,

var create = function (socket, signature) {
    var e = event('create', signature), data = [];
    socket.emit(e, {id : 1});
};

What do you create ? Looking at the code you create an event and then you emit it.

var createAndEmitEvent = function (socket, signature) {
    var e = event('create', signature), data = [];
    socket.emit(e, {id : 1});
};

Here you know by its name. Therefor you don't need a comment block. This block code block doesn't respect the single responsibility principle but principles are meant to be broken. A 2 lines function doesn't need to be splitted.

I would also allow some duplication in the signature.

var createAndEmitEvent = function createAndEmitEvent (socket, signature) { 

The purpose of this is to have the name of the function in the stack trace in case of an error. Otherwise, the function will be identified as anonymous.

Here's another example.

socket.on('init', function(data){
    if(hs.session.userdata){
        fs.readFile(__dirname + '/assets/tmpl/user/dashboard.html', 'utf8', function(err, html){
            if(err) throw err;
            socket.emit('init', {callback: 'dashboard', tmpl: html});
        });
    }else{
        fs.readFile(__dirname + '/assets/tmpl/user/login.html', 'utf8', function(err, html){
            if(err) throw err;
            socket.emit('init', {callback: 'login', tmpl: html});
        });
    }
});

You could create a function called onInitSocket. You also have a another callback inside this function to handle the readFile callback. This is a smell. You could handle this case using promise or using the async module. I recommend the latest in your case in order to not change the paradigm. You also have a variable called hs. If you split your code in functions and later in different file, it won't be so obvious that this name refers to handshake.

Overall, make sure your code speak for itself. You should only have to use comments when the code needs to be unclear (algorithme optimization for instance).

Before trying to split the program into separate files, I would suggest first commenting your functions to explain what they are accomplishing in the context of your application. Then, add comments that group things under a specific "section", e.g.:

    /* --- INITIALIZE ALL GLOBAL DATA FIRST --- */

    var initializeFirstDataSet = function () { ... }();
    var initializeSecondDataSet = function () { ... }();

    /* --- VALIDATE USER INPUT --- */
    /*
     * Our application is especially sensitive to erroneous user input;
     * therefore, we will provide additional overhead to user input validation
     * and stop all further processing if any input is invalid.
     */
    /**
     * we provide our users the flexibility of giving email addresses or phone numbers
     * as user names. ensure they have entered in one of those here.
     * NOTE: we will not test whether the user name itself exists here, only that
     *       it's possible that the input could be a user name.
     * TODO[me]: our application may be using a more systematic validation
     *           from other parts of our system. include that here via another
     *           file if available. 
     * @param userName String - email address or phone number
     * @return Boolean - whether user name is of valid format
     */
    var validateUserName = function (userName) {
        // do regex-matching and other necessary validation here

    }( /* input GET/POST parameter here */ );

    /* --- WIRE LIFE-CYCLE EVENTS --- */
    /*
     * our application has a number of events that are part of the normal
     * "lifecycle" of a REST API. include the handlers here.
     * TODO[me]: is there 
     */
    var create = function () { ... }();

As I spent time commenting the various sections of my code and trying to group them, I realized that some things may be retrieved from other files, and some things may be moved to another file for more streamlining.

At the very least, once you start commenting, your code becomes more understandable to someone who has not seen the code before.