So basically there are two possibilities:
a) you can patch all the build code and plugins to make it compatible with node.js
b) you can define a window object as this and override some of its methods (i.e. navigator, XMLHttpRequest etc.) prior to loading your build, so that when you start your build, it will think that it is running in a real browser, and not in the shell.
The second approach seems to be much more universal to me, because:
you don’t need to patch the build code
you only have to implement such a wrapper once and it will work for future versions of Unity
you can use the same approach to run your build in other shells.
Still, there is one problem that would be a bit complicated to solve. It is the canvas context functionality (used in gl functions), which does not exist in node.js. Even though there is a working example of a headless canvas in Emscripten code, it is not functional enough to cover all the Unity calls (unless you spend some time to make it work). However, if you just want to test your code in a shell, you can try to create a Development build, which should use a native NullGfxDevice when WebGL context is not available. To check if this functionality is available in your build, disable WebGL in your browser settings and try to run your build. If it runs well with a black screen, then NullGfxDevice code is included in your build and it should also run well in a shell without additional adjustments (otherwise it should print “Could not initialize WebGL context. Failed starting Unity.” in the console).