First off, welcome to the world of TFS. :)
There is nothing wrong with how you wish to work. The hierarchy you outlined is fine, and TFS will support any set of Work Item Types (WITs) and relationships (links) you require them to have. The Implementation tab, and all other tabs that show relationships with other WITs are merely filters to the entire list of WITs your type is related to (i.e. the Requirement's Implementation tab shows all work items that are of type Requirement or Task, and have a parent/child relationship).
What follows, is that you should think what artifacts (WITs) your process requires, and how they should work together, and customize your process template to work as you want it to.
This is relatively simple to do, especially when you use the process editor that is part of the Team Foundation Power Tools. If you want to modify the link pages, it is all done in the layout part of the work item type.
Regarding the question of the relationship between requirements and tasks: I always view requirements as the definition of what the user / customer needs. The requirement should be more outward facing, describing the need, the goal and the desired effects (and side effects). The tasks are more inward facing, and should tell the developer how he (or she) should go about achieving the above goals.
With that in mind, I always prefer to have a developer work only on tasks. Moreover tasks should always derive from a requirement (or a bug, or a change request, and so on). A task that doesn't come up as the result of a requirement might indicate that the work is either unnecessary or poorly planned.
Hope this helps,
Assaf.
