To answer the specific question, it's absolutely possible that grouping tests into multiple classes is a good decision, event when the class under test is well designed.
Unit test code is like any other code: it should follow good design principles (DRY, GRASP, KISS, SOLID, YAGNI, etc). Because the logic that makes up test code is often simpler than domain logic, a lot of the specific points won't come up as much, but keep them in mind while writing your tests all the same.
There are a couple of principles that come to mind that can easily apply when thinking about your question:
Ideally, once a test is written, you never have to look at it again; but the same can be said for any code. The reality is that requirements change, so we find ourselves reading code much more than writing it. Even when doing your best, you may find that the test you wrote didn't quite verify what you thought it did, at which point you'll have to go back in and figure out what was wrong. Finding that test method in a class of 40-50 test methods is going to be tough, not to mention the complication of naming those methods so they can be differentiated easily.
Each test class (like any other class) should have a clear focus. If you have a lot of different test cases for a given method of the class under test, as when a given test verifies a single thing, put those test methods in a separate class and name it to reflect its focus.