GameState Management efficiency
I can't be sure of this (I need to foster my XNA knowledge), but I would probably derive that class from DrawableGameComponent so that the Update and Draw methods would be overrides (not just methods that happen to be named &quot;Update&quot; and &quot;Draw&quot;), but deriving from that class might have other consequences that I'm not aware of; again, my XNA is fairly basic - it just seems natural to me for a class that has Update and a Draw methods, to derive from DrawableGameComponent: these method names are not an accident.
Update
Your Update() method is looping through each GameScreen and calling Update() on them all:

foreach (GameScreen screen in gameScreens)
{
    screen.Update(gameTime);
}


I think doing this incurs non-necessary processing: why would you bother updating the splash screen and pause screen at every single iteration? You're wasting cycles here.
Draw
Your Draw() method is more selective:

public void Draw(SpriteBatch spriteBatch)
{
    switch (ScreenState.Instance.CurrentState)
    {
        case State.Splashscreen:
            gameScreens[0].Draw(spriteBatch);
            break;
        case State.Menu:
            gameScreens[1].Draw(spriteBatch);
            break;
        case State.Play:
            gameScreens[2].Draw(spriteBatch);
            break;
        case State.Pause:
            gameScreens[3].Draw(spriteBatch);
            break;
    }
}


I like that you're using an enum here, but I don't like that you've hard-coded the gameScreens indices. Let's see.. you're storing the screens in a List, here:

List&lt;GameScreen&gt; gameScreens = new List&lt;GameScreen&gt;();

public ScreenManager()
{
    gameScreens.Add(new Splashscreen());
    gameScreens.Add(new Mainscreen());
    gameScreens.Add(new Playscreen());
    gameScreens.Add(new Pausescreen());
}


Allow me to open a nitpicking parenthesis here:

Nitpick
Instead of List&lt;GameScreen&gt; gameScreens = new List&lt;GameScreen&gt;(); and then adding the screens in the list at construction, I would have used an interface here, and initialized everything in a single statement:
private readonly IList&lt;GameScreen&gt; _gameScreens;

public ScreenManager()
{
    _gameScreens = new List&lt;GameScreen&gt; 
                           {
                               new SplashScreen(),
                               new MainScreen(),
                               new PlayScreen(),
                               new PauseScreen()
                           };
}

This allows the _gameScreens private field to be readonly, which prevents the list's reference to be tampered with.

The mechanics work, but could work better if you leveraged IDictionary and turned List&lt;GameScreen&gt; gameScreens into a IDictionary&lt;State, Action&lt;SpriteBatch&gt;&gt;:
private readonly IDictionary&lt;State, Action&lt;SpriteBatch&gt;&gt; _gameScreenRenderer;
private readonly GameScreen _splashScreen = new SplashScreen();
private readonly GameScreen _mainScreen = new MainScreen();
private readonly GameScreen _playScreen = new PlayScreen();
private readonly GameScreen _pauseScreen = new PauseScreen();

public ScreenManager()
{
    _gameScreenRenderer = new Dictionary&lt;State, Action&lt;SpriteBatch&gt;&gt;
                            {
                                { State.SplashScreen, sb =&gt; _splashScreen.Draw(sb) },
                                { State.MainScreen, sb =&gt; _mainScreen.Draw(sb) },
                                { State.PlayScreen, sb =&gt; _playScreen.Draw(sb) },
                                { State.PauseScreen, sb =&gt; _pauseScreen.Draw(sb) }
                            };
}

An Action&lt;SpriteBatch&gt; is a delegate that points to any method that returns void and takes a SpriteBatch parameter; here the method is anonymous.
Each GameScreen becomes a field of the ScreenManager class, there's no need to have them in a list of any kind. Doing this turns your Draw implementation into something like this:
private void Draw(SpriteBatch spriteBatch)
{
    _gameScreenRenderer[ScreenState.Instance.CurrentState](spriteBatch);
}

Implement a similar mechanism for your Update method and you'll only be updating and rendering the screen for your CurrentState.