I understand that all InProc session data is always gone when its w3wp owner process recycles as it only resides in the w3wp memory.
I wondered though if it is possible to cache the session data when recycling happens somewhere external to the process, and then reinject (and rebuild) the session when it comes back up. That way I'd get the speed of InProc with the reliability of state server-like externalization when necessary. Is this possible?
No, this isn't possible. There is no API to "warm up" in-process session state or cache. Such a solution would be unreliable anyway. You couldn't gaurantee that the last thing your app did would be to export its current session state, so you could never count on the imported data to be current anyway.
You can use the out-of-proc state server on the same host as your web application. Then the web application can recycle freely, keeping the state information intact. This is quite a bit faster than using SQL Server to manage sessions, as you don't have to deal with the overhead of SQL or network transit to another machine, the only way it's worse than in-process session state is that data has to marshal across process boundaries, but as long as you don't have a massive amount of rapidly changing session data, this shouldn't be noticeable at all.
There are also other alternatives, such as Microsoft Project Code Named "Velocity" or ScaleOut Software's SessionServer (among others I'm sure) that offer distributed caching mechanisms that can keep session state or cache synchronized between servers in a server farm without having to resort to using SQL Server.
Contrary to what another user posted, I would NOT use ViewState to store session data if at all possible. For one, it's not true session state, if a user moves back or forward it can be lost. Second, it's fairly insecure. Third, it causes massive page bloat if abused.