As others have pointed out, it wouldn't be a good idea to make User return a collection. This is mostly a semantic issue: a User is a single person, so anybody who is unfamiliar with your software will rightly expect it to handle only one such entity and not return a list. This will include you in a couple of months time when you re-use the module and surprise yourself with the behaviour of your User class :-).
So, here is a different approach: why not have a UserList class? Objects of this class could be instantiated with a list of IDs and use a single DB query to get the data, then internally create a list of User objects from them, which it can then return. It would be used like this:
my @userlist = UserList->new( ids => [ 1,2,3 ] );
foreach my $user (@userlist){
print "user's name is: ".$user->user_name;
}
The code for building the UserList object is basically what others have given you already but now you have an appropriately named class with a clear purpose.
Now, having said all of that, you are in danger of creating your own Object-relational mapper. Have you checked out existing solutions like DBIC?
You will see exactly those concepts there with a separation of sets of results and then the actual result, representing one row of data from the DB.
