As there is no inherent relation between a use-case and a GUI screen, it does not really make sense to divide use-case diagrams the GUI screen they relate to.
To elaborate, a use-case describes how an external actor (either a machine or a human) interacts with a system to achieve a particular goal for that external actor.
If the use-case does not involve an interaction with a human, there are no GUI screens involved either. And if the use-case does involve a human actor, then the GUI could be anything from a single button (e.g. to print the current document to the default printer) to multiple screens (e.g. a class creation wizard in an IDE).
Good use-cases don't even mention the existence of a GUI. It just specifies that actor X provides A, B and, optionally C pieces of information and leaves the how for the design team.
If there are many use-cases, then it can be good to split them into multiple diagrams, but that should not be based on a design choice (how the GUI is organised). Better lines of division are
- having use-cases that deal with similar functionality on the same diagram
- having use-cases that interact with the same actor on the same diagram