If I were doing what you're doing, I think I'd use the
ClassExtender extra to extend the modUser Object and add your fields. They would go in a separate table, but still could appear on the Create/Edit User form in the Manager. I would use Subscribe (and Notify if you need to send messages to your users). I think a postHook on the Register snippet could save the user data from the Register form to the extended user fields (and record user preferences if you need them for Subscribe -- e.g., email preferences).
I'd separate the PayPal process to a separate page with a snippet or processor that would get the information back from PayPal and set the appropriate extended user fields, and forward the user to a welcome page with a link, or links to where they might want to go.
I'd also put a simple snippet on the protected pages (or in their template) that checked the custom table to see if the user had a current paid subscription, and if not, forwarded them to the PayPal page, perhaps with a $_POST or $_GET variable indicating if they were new (never paid) or needed to renew.
Another approach (still using Subscribe and the general techniques above) would be to shoehorn your user data into unused fields in the modUser or modUserProfile objects:
modUser:
remote_key (string)
remote_data (json)
hash_class (string)
createdon (timestamp)
modUserProfile:
mobilephone (string)
dob (integer)
gender (integer)
address (string)
country (string)
city (string)
state (string)
zip (string)
fax (string)
photo (string)
comment (string)
website (string)
extended (json)
That would avoid extending the modUser object, but would require some messing with the Lexicon strings used for the field captions, and you'd have to remember which field held which data, since the field names wouldn't tell you. You'd also need check the field lengths in the DB to make sure your data would fit.
Hope this helps.
☆ A M B ☆