I think that the problem here is that even if you do find a list of users, the workflows won't trigger any actions if the users don't exist in the User Information List.
If the users don't exist in the User Information List, then you won't be able to find them via the SharePoint object model because they don't exist in SharePoint. You will have to find them some other way.
So basically, it depends on how the authentication is configured on your SharePoint server :
If you are using FBA, then the users who can authenticate with SharePoint must exist in a SQL database somewhere. Membership.Provider will give you a hook on your FBA membership provider (whether it's a SqlMembershipProvider or something else). You can then use methods like
Membership.Provider.GetUser(username)
to see if a user exists. You can also loop through your users or find all the existing usernames which you could then display in your people picker.
If you are using windows authentication, you will have to look in your AD to find the potential users. The DirectoryEntry object is what you'll need. I imagine that only users from a certain AD group can access SharePoint? If so, then isolate that group with the DirectoryEntry object, loop through the users and you will have your data source for the people picker.
As I said above though, either method will give you the possible users, but it won't make the workflow work if the users have not logged in. Workflows will only work properly with users that do exist in the User Information List.
When someone picks a user that doesn't exist in SharePoint, you will probably have to create it via code. A safe way to do this is with the SPWeb.EnsureUser.
Checks whether the specified login
name belongs to a valid user of the
Web site, and if the login name does
not already exist, adds it to the Web
site.site.
So really, to answer your question, nowhere. You need to look for them where they could be coming from.
