Well, login is a bad example to use, despite the fact that far too many
Java books do so anyway.
Like I said, the builtin security system has a builtin security API, so you wouldn't be getting the user ID from a session variable, you'd be getting it from a security method.
On a broader basis, however, the only difference between HTTPSession objects and JSF session objects is that JSF has automatically constructed and initialized (via property setters) the session object automatically, whereas in a
servlet or JSP, you'd have to do the job manually.
A JSF session bean can be injected into another JSF bean of equal or higher scope (session or application) using the JSF Managed Property option - either coded as part of the target bean definition in faces-config.xml or via annotations (JSF2 and later).
A non-JSF session bean has to be found the hard way by getting the HttpServletRequest object from the FacesContext and applying the getSession().getAttribute() method chain. I keep a separate JSF utility class that I can employ for that kind of stuff. It helps keep JSF-specific code out of my backing beans and makes it easier to unit-test components offline.