So basically if you have an infinite loop in your app's one and only thread, none of the callbacks will happen because they have to run on that one thread?
Yep. Similar to how an infinite loop in the browser will freeze up the page - the browser only gets to control to draw by putting a draw function in the event loop, so if you hog the thread, the page can't update.
No, Javascript has no notion of threads. Rather than true concurrency and a synchronization mechanism, it has callbacks (upon callbacks upon callbacks).
Technically speaking, HTML 5 introduced web-workers which allows javascript to have multiple threads (see 1). However, it's still useful to think about them as being single threaded since workers are sandboxed, meaning they don't have access to the global namespace. This avoids issues commonly found in concurrent programming. E.g., separate threads cannot read and write to the same variable since they don't have access to each other's namespaces.
People coming from multi-threaded server environments should be aware that multi-threading does in fact exist in Node (scope of parent comment), but it's rather different from other more common concurrent event handling schemes. I.e., you cannot have shared mutable variables across threads (scope of article and ongoing async discussion). For examples, see https://npmjs.org/package/webworker-threads and https://github.com/cramforce/node-worker.
Once one of those activities completes the event loop will give a signal to the main thread of the Node app and the callback will be executed.
Not sure if that helped or just confused everyone.