Soheil-
A USERNAME and its associated USERID value are both treated as unique identifiers for user accounts -- that is, you cannot have two of the same values within a single installation of DNN. DNN is designed so that a user may leverage a single account across multiple portals. This is why you get the "user already exists" message when attempting to create a second account "David" with a different password. Using the same password "links" account "David" across portals -- that is, if you change any aspect of the account "David" on one portal (password, email, etc) the change is immediately reflected on all portals with user "David".
This design can be viewed as both as a good thing and as a nuisance. On the positive side, this design means that it's difficult for someone to impersonate an existing account "David" on a separate portal within the same DNN instance (because both USERNAME and PASSWORD must match the existing info in order to create/link the account on a new portal). It's also nice in that the design allows your users to leverage a single account on multiple portals.
On the down side, if your portals are not related then you probably don't want to allow single accounts to be linked across portals. This design can also generate a lot of confusion for admins who know that there is no account "David" on their portal but who also don't have the knowledge/access to see that account "David" is already created in a different portal (a real problem in hosting environments where different portals have no knowledge of each other).
I'm not aware of a module that allows you to do what you want. That's not to say there aren't modules availalbe -- I'm not just aware of any and a quick search on SnowCovered didn't turn up one that does exactly what you're after.
Potential Workaround: Append PORTALID to USERNAME
You could hack around this by using custom REGISTRATION and LOGIN modules that silently appended a portal identifier (PORTALID) to the end of the USERNAME value whenever a user creates an account or logs in or requests a password reminder. For example, user "David" would become "David.00" for the root portal, "David.09" for the tenth portal created, etc. This would do what you need and be fully in keeping with DNN conventions (i.e., this solution won't break any modules).
Using Core DNN
If you wanted to force this method without using a custom solution you could simply add instructions to your users to append the PORTALID value to their chosen USERNAME during account creation (and to use the appended version when logging in). You'd also want to add a REGEX validator to the USERNAME field to be sure a user appended the needed ID value. For the default DNN registration, you'd need to update the file "USER.ASCX" under the "CONTROLS" folder (note: this file will likely be overwritten when upgrading to newer versions of DNN so you must be prepared to re-apply the change).
I don't generally advocate changing DNN core code. If you decide to do so, though, you'll also be interested in how to add special registration instructions that won't reappear on the USER CREDENTAILS page for already-created accounts. See my post on custom registration instructions here:
Add custom registration instructions to the DNN user account registration page
http://www.eguanasolutions.com/DNN_Blog/EntryID/3.aspx
Third Party Module?
A good compromise (to force appending PORTALID without changing any core code) might be to use a third-party custom-registration module that supports adding REGEX to any field. One such module is from DataSprings -- see it here: http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=6747
You can see the DataSprings validation options on page 78 of the user manual here. Having the DataSprings module (or one like it) opens up a range of other features. For instance, the module supports addition of custom client-side scripting so you could auto-append PORTALID to USERNAME. Refer to the user manual (150 pages!) for all features.
Hope the info helps-
-mamlin