Since it is most likely that the logic of your game will not change from level to level, rather it is the content that changes - map, characters, enemies - it doesn't make sense to create a new screen for each and every level.
Each new level screen will be almost identical to the previous ones except for maybe a few properties, fields, and the Initialization and LoadContent methods. Most of the fields, properties, and methods - such as Draw and Update - will not change.
Thus, it makes more sense to have one GameplayScreen and create something like Level and LevelManager classes to handle the switching from one level to another. If you want something even simpler, you can just have a method on the GameplayScreen that switches levels and handles the transition while switching.
My recommendation would be to go through the rest of the tutorials on the App Hub site or at least go through some of the labs or kits that actually document the creation of a full games using the Game State Manager. Labs are tutorials that take you through the creation process while kits are full games with lots of comments in the source that you can use as a building block for your own games.
The Role-Playing Game Starter Kit uses the Game State Manager and shows one possible level management solution. They create a master Session class that handles the game play and the switching of levels - or in their case switching Maps. Also, this kit uses a number of screens like ChestScreen, DialogueScreen, etc., which will give you a better understanding of what Screens are used for.
Also the Platformer Starter Kit is another game that shows how to work with levels, but doesn't use the Game State Manager. But, it wouldn't be hard to integrate their mechanism into a game that uses the Game State Manager.