You are essentially asking things that are dependent on the inner workings of the JS engine. A JavaScript program can go through many phases, including a "parsing" phase, but in practice there are different kinds of parsing occurring in multiple phases, at different levels, for different purposes. (I would not call this the "Creation" phase; that term is non-standard and confusing.) The result of various parsing stages can be an internal syntax tree, or an intermediate byte-code representation, or even machine code ready to be executed. The same code might be parsed in different ways at different points in time, or in some cases parsed and then the result thrown away and reparsed again later, etc.
The whole point is that, unless you are learning compiler theory, it doesn't matter. Yes, parsing can be considered to be where "hoisting" occurs. However, I would urge you to not spend too much time worrying about hoisting, unless you plan to enter some kind of JS trivia contest. Just declare all your variables (including variables to which you assign functions) at the top of each function, as you should have been doing all along, then stop worrying about it. While the other guys are patting themselves on the back for knowing whether or not ES6 classes are hoisted, you can be actually writing useful code.
The question of when and how and where memory is allocated is also an internal engine detail. Some items might be allocated on the "heap" (of which there might be more than one), and then garbage-collected later. Such allocation would almost always happen at run-time, but this is also not a hard-and-fast rule; for example, a regexp encountered identified during parsing might be cached in compiled form on the heap. Other variables, such as primitives, are likely to be allocated on the "stack", and de-allocated semi-automatically when the stack frame is released when returning from a function. Variables which need to be maintained for use in embedded functions ("closures") are allocated and stored in a particular way.
I doubt if knowing any of this is going to make you a better JavaScript programmer in any meaningful way. Learning how one engine does it is not going to necessarily help you understand how another engine does it, or even how that same engine is going to do it in the next version.
Do you have a specific reason for wanting to know this, other than curiosity, or a specific case where you think it would make a difference?