There are no technical restraints regarding the ten object limit. This is actually mentioned in the documentation somewhere. However, if salesforce.com finds out (however that may be), you would be in violation of your contract and at risk for contractual breach.
In theory, this means you'd be forced to pay for the more expensive licenses that you would have paid for if you'd been upfront about needing more than 10 custom objects to begin with, backdated to the point where the breach of contract occurred.
As long as the users can only view data from ten different custom objects, they should be fine under the contract. For example, it would be particularly cumbersome if you couldn't write a trigger to update an 11th object they don't have access to when the trigger does so for users not under the 10 object limit.
Writing Visualforce pages to circumvent this "restriction" would be pointless, because there are no technical restrictions that would enforce this limit. However, do keep that limitation in mind when building your UI and code, because a breach of contract isn't ideal for your organization's pocketbook. You should not be exposing more than 10 custom objects total (not including Managed Package objects, as noted here).