My company has created a product that is designed specifically to address needs like this. The problem we faced was that the purpose of custom field definitions is to define how data is stored, rather than where it comes from or how it is entered. FieldTypeDefinitions can create some real problems in your environment (if it ever gets corrupted it will break access to ALL columns in your environment, for example). Resolving issues require reboots and IISRESETs during production hours. It's a messy technology to solve the problem you're looking to solve.
What we've done instead is create a couple things we refer to as Transcriptions and Expressions: Transcriptions are different types of formula that you can use for applying custom values (like user profile properties) to existing field types, and Expressions are little bits of script that you can apply to specific fields. So (for example), you might apply an Expression on your 'Favorite Color' column that automatically sets the value to a user profile property through the User Profile Transcription.
Notice that we are applying the above script (using the {User.Email} Transcription) to the "Single line of text" column below:
So when we open our form, the default value is the Email address from our User Profile property:
This is all essentially handled through the use of custom forms, with custom field iterators. When you launch your NewForm.aspx, our control gets loaded instead of Microsoft's, and we use it to add these extra features at runtime.