The mediator and view component are necessarily coupled. A given Mediator will only be used for mediating communications between a given view component and the rest of the system.
That said, it is up to you to choose the tightness of the coupling. The most loosely coupled way is, as you say, to exchange that data using a custom object or VO, passed to the mediator via a custom event.
From the Best Practices document (page 25):
A Mediator usually has only one View Component, but it might manage several, such as an ApplicationToolBar and its contained buttons or controls. We can contain a group of related controls (such as a form) in a single View Component and expose the children to the Mediator as properties. But it is best to encapsulate as much of the component’s implementation as possible. Having the component exchange data with a custom typed Object is better.
If you create a view component that is simple, and it only has one or two properties that the mediator needs access to, then creating a custom event AND a VO is overkill. A more reasonable balance between coupling and complexity (number of files involved in this case) is to simply create public properties that are considered the 'API' exposed to the mediator. Inside the view component, bind the text fields (or whatever subcomponents) data to these properties such that when an event is dispatched, the mediator inspects these API fields (not the text boxes).
If the view component has many properties to be passed, you can still avoid creating a custom event by having a single complex object (VO) as an exposed property, dispatch the event and allow the mediator to access the VO property.
Again, I am not saying that you should not do as you suggest; creating a custom event to carry the data, only that there is a balance between complexity and coupling to be made with each mediator/view component pair. But I am agreeing with you whole heartedly that the mediator should not be so intimate with a view component as to know its children and access them directly. This limits our ability to refactor the view component's internal implementation without also refactoring the mediator.