Q1 and Q2: Yes you can package your profiles, however you must ensure during installation of your package the user selects Security Configuration, here they must map your packaged profiles to those in their organisation. This is really important as it is a one time only operation. This must also be repeated during upgrades.
Q3: Yes customers can define profiles referencing your packaged objects, tabs, apex and visualforce pages manually. Though its not an easy task if they are unfamiliar with the structure of your app, also it can be quite a task if they have many many profiles.
Q4: You can read Permission Sets which reflect Profile information, but you cannot write to it, at least not from Apex directly. You can use the Salesforce Metadata API from Apex to deploy Profiles, though I would recommend another thought before thinking about this...
I would strongly recommend you review this platform feature instead of using Profiles. These are the benefits of Permission Sets over Profiles.
- Permission Sets like Profiles express access to components in your package. However they are typically expressed in terms of functional modules in your application and not what you think might be roles in the target organisation (as has been historically the approach with Profiles).
- Permission Sets can be packaged and are upgradable.
- Permission Sets can be shared amongst users by assign them (new features in Spring'14 make this a lot easier). You can assign more than one Permission Set.
- Permission Sets can be assigned after installation.
- Permission Sets can be copied if the users want to modify yours.
Hope this helps!