I'm not clear what you're trying to do. You want to create a mock, such that calls to getList(int) in the code you're testing actually call getList() with no parameters? I don't think that's possible, but of course you can mock getList(int) and have it call getList().
If your mock's purpose is to bypass the database, then you have to get the data from somewhere else. In your first mock, you load it up from a "things" object, but you don't show where that object is created or populated. In any case, I would have your second method go through "things", pull out the members that match "id", and then return those as a list.
Well, mocks are used for testing, so if it adequately tests your logic, then it is correct in that sense. I assumed that you would want to filter "things" by the id parameter to better mimic what the original method does. Your second mock doesn't do that, so in the sense of following my suggestion, no, it isn't correct.
What is your test case? Is it really necessary for your mock to filter a bunch of test "things" in a manner analogous to what is done by the working application? If so, it should be a trivial matter as Greg indicated to iterate over the map's contents and return those things which have the required id. However you might consider whether perhaps your test is attempting to handle more responsibility than is necessary. If the DAO layer has its own suite of tests that cover this same logic, then really it ought to be sufficient to verify that a call was made to the DAO, and that Something was returned by the service. (Of course if the service has additional logic to perform, the test should cover that too.)