This idea about TDD is that you start with a single test and start building code from there to furfill the test.
You have a couple of levels of test, as described in the test-pyramid, you can start with a UI (end-2-end) level test and then this should result in Service and Unit level tests.
In your case the Acceptance criteria are the UI level tests, but you do not keep them in an Excel-sheet, but they should be executable tests by code. For example with Fitnesse or Cucumber.
Full TDD cycle:
The whole TDD flow is a bit bigger, as described in this video Test-Driven Development (that’s not what we meant) by Steve Freeman

On the fourth level it starts with "Writing a failing end-to-end test" which is followed up by "Write a failing unit-test". You do not even talk about unit-tests in your question.
Also your example start with the login tests, although you might need a login fucntionality this is not a suggested start. Start focusing on feature value and only build a login when you really need it.
Practising TDD:
TDD consists of 4 main skills: Driving development with Tests, Refactoring safely, Designing test cases and Designing Clean code.
To practises skills multiple kata's have been designed, you can start with the StringCalculator kata. Just start with the most simple test you can imaging, something like testing input "" returns 0. The rest should follow from there. The coding dojo handbook has a long list of kata's to practise all TDD skills.
Suggested reads: