Yeah, this is not going to work very well in the end.
A big problem you haven't considered is that this whole concept will fail miserably in a clustered environment (a 'lock' held on one instance is not visible to the other instances, thus allowing multiple users to get a 'lock' as long as they are on different nodes).
Basically you will never be consistently invoked via window.onbeforeunload() event handlers. Users can close the browser, the browser can crash (either due to your app or another tab that they have open, etc). Relying on this mechanism is prone to failure. It's why session management has a timeout; there's just no way to be absolutely sure the remote browser is still there, so the server side has a timer to expire the session (and Liferay has the corresponding browser timer so you can extend and ack you're still connected).
Now for the SessionAction guy, you have to remember that there are multiple sessions involved. First, you have the session tied to your web application that your portlet is deployed within. This session is pretty meaningless and you shouldn't really bind to it at all. Then there's the portlet session, this is outside of the servlet sessions but has a similar concept. I don't think you can register on expiration of these because individual portlets don't expire individually.
Then there's the session tied to Liferay's root application. This is the one that you'd need to bind to in order to catch the session expiration, but you can only do this via an EXT plugin (because it has to be part of the ROOT web app). Of course, once you're in ROOT's context, you won't have visibility to any beans defined for your separate web application.
What you might consider for this case is using the LMB. That's not really context-sensitive since it's messaging, so the ROOT session listener could send a message indicating that the session is gone.
But the issues surrounding this kind of "locking" concept will make it difficult to manage. Even with the session timeout logic, without some sort of intervention by an admin, the lock would be hold for as long as your session timeout window is, and this may prove disruptive for the other privileged users who have similar permissions.
I'd try to rethink the lock concept entirely. If your issue is that only one user can do something at a time, there are better ways of enforcing this sort of thing. The LMB, for example, would allow multiple users to submit messages to a destination, but those messages are processed synchronously so you get the "only one at a time" thing that you need.
