Welcome to the JavaRanch, Daniel!
I'm not sure that anything that you're looking at here is really JSF-related, unless you're making the common mistake of thinking that JSF backing beans are MVC Controller Objects (they're not - they're slightly impure MVC Model Objects).
However, here's a scheme that's been working well for me:
Forget the crusty old "3-tier" model. These days I have more like 7 or 8 tiers - assuming you're willing to count a couple of layers on the client for AJAX support and the like as tiers. However, the tiers of most interest for you, I think are these:
A. JSF backing bean. Provides the presentation model for the UI tiers.
B. Business layer. Platform-independent business logic (where applicable). I don't always need this.
C. Persistent Data Services. Similar to the Business layer, but this layer handles complex ORM interconnections. For example, if I have a parent/child complex of entities, this layer is responsible for access and management of those objects and their interrelationships. Layers A and B work with detached ORM objects. This layer runs most of its methods as transactional and attached, returning detached objects.
D. DAO services. Although I started out with layers C and D in one big mish-mash, these days I find it cleaner to keep per-table ORM access here. This layer knows ONLY basic data access without relationships or business logic. That makes writing
unit tests easier, and I've found that unit tests are a Good Thing, since ORM frameworks tend to work with interpreted query languages that cannot be validated at compile time.