The reason I think you have asked a great question here is that you really pinpointed the major impediment to delving into TDD--what do you test next? Answering that question is much easier with just a few notions clear in your head.
(1) TDD, contrary to the name, is not about testing.
“Folks who do TDD for a while typically come to the conclusion that
the only thing that TDD has to do with testing is the appearance of
the word test in its name. That’s a bit of an exaggeration, but it’s a
common one used by TDD’ers to help clarify the issue. We use unit
testing frameworks to do TDD, and we write the example code in methods
that can be executed by the test runners that come with unit testing
frameworks, but that’s about the end of the commonalities between TDD
― Scott Bellware, Behavior-Driven Development
(2) The goal of TDD is not to come up with tests; it is to come up with specifications (or behaviors).
“The entities we write are not actually tests. They are
specifications. What we are doing is replacing traditional specs with
automated specs. The process of writing the specification is an
analysis task, one that leaves behind a suite of tests as a
side-effect artifact...” ― Scott Bain, Overcoming Impediments to
(3) To determine what to test next (or even where to start) the question then simplifies to: What is the next most important thing the system does not yet do?
(Let me touch explcitly upon a point implicit in Telastyn's answer: your question suggests you are trying to align unit tests with user stories, but they exist at different levels in the architectural hierarchy. Unit tests--the byproduct of TDD--are much closer to the implementation, much more fine-grained.) So the "next most important thing" refers to implementable thing, not user-story-level thing.
(4) The answer to the question in (3) should be some behavior B. Write that behavior B as a sentence S0. If the sentence is too long or convoluted split it up into multiple sentences S0, S1, S2 ...
Each such sentence Sn names one test.
So with these simple ideas in mind, not only can you figure out what to test, you also come away with the test method name... leaving you with "just" the implementation left to do.