Does this count as a user story for a basic Sudoku game?

Your examples can count as user stories, but they are missing a very important part: the goal that the user wants to achieve when the story is implemented.
This goal might be obvious to you, but you should write it down anyways.

A user story has the format

As a <user> I want <feature> So that <goal> 

The goal part is important, because it helps the developers in making the right decisions.

Your second example could have two very different goals, that would lead to different designs.

• As a new player, I would want an introduction level to the game to teach me the basics, so that I can solve the game and get a sense of accomplishment
• As a new player, I would want an introduction level to the game to teach me the basics, so that I can learn the rules of the game

In the first case, just having an easy level would be sufficient, but in the second case you want to guide the user why a certain number must/mustn't be placed in a particular cell.

In addition to the good point that Bart mentioned regarding the goal, I'd like to focus on the "agile" part. Even though what you have are user stories, they are way up there on the "epic" side of the spectrum and are not yet useful for development.

As I see it, you would generally start with stories like the above when you're initially planning a new product or feature, to get a good feeling of what you want to build, and then you'd start breaking these kinds of "epic" stories to smaller and smaller chunks until you have a set of stories that is directly actionable for development. In particular, when practising Test-driven Development (TDD), you'd like to get to a level of granularity such that each user story is naturally translatable to just a few test cases (although each might still be complex).

Examples of such more actionable stories might be:

• As a player, I want to ask the game to generate a solvable Sudoku board for me, so that I could start planning my approach.
• As a player, I want to be able to fill values in the cell, using my mouse and have the game indicate whether the value makes the board invalid, so that I could quickly try out possible options and backtrack if needed.

I would recommend the following excellent post by Alex Cowan to learn more about this: Your Best Agile User Story.