Well, no matter the server code you have running, if there is a foreign key constraint on the UserProfiles table and you create a profile row without a corresponding user, you'll get an error. You shouldnt have to remove the constraint, you just need to create the user first.
Anyway, I am not really following the latest post. you say:
'but only in my custom Membership table called UserProfile'
To be clear, this patch has nothing to do with profiles. We dont even use profiles (thats why I am using this patch, so we can add columns to the member table). My suggestion is to disable all the profile setting/getting/handling code and try to figure out why the provider isnt creating a user when you call Membership.Provider.CreateUser. If/when that works, then move onto the logging in action. All the stock Login control does is call Membership.Provider.ValidateUser (then it does some cookie magic that has nothing to do with the provider), so try to get that to work. You could just setup a new project that uses your generated code and uses all the stock auth controls. That's what I would do, reduce it to the smallest amount of potential errors.
Now, are you sure you are generating the code correctly? You need to point to the proper membership table, the proper PKID of that table, etc. (all of which is done through the codesmith interface). Is that all taken care of?
Troubleshooting this is difficult without seeing the schema, your codesmith settings, your web.config, and your code.
Ben