If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.
You seem to be referring to the "incompletely initialised object" anti-pattern. The books I have about concurrency in Java/on the JVM strongly recommend making Java objects immutable when you can. Even in Visual Basic, if an object is "constructed" via a lengthy sequence of steps, it is good design to distinguish between two different things": a fully constructed Foo object and a FooBuilder object. Sometimes they need to be the same object, but there really do need to be two *interfaces*. Once past the construction phase, you want to KNOW that the object is fully constructed, and there are things the constructor might do that you DON'T want other objects to do. Reflecting on the use case you are talking about, it seems to be that there are two conceptually very distinct objects here. There is a FooForm object which is intimately connected to the user interface and may only partially describe a Foo, and there is a Foo object which is *not* connected to the user interface or if it is, is connected in a quite different way, exposing quite different behaviours. Reflecting further, suppose I fill out a form and press a button to commit this object, then I edit the form to be a little different, and press the button again. Creating a new *object* by revising a single *form* is clearly distinct from *editing* an existing object. What I think about this, therefore, is that you want a clear distinction between FooForms and Foos (at the very minimum a distinction between FooForm and Foo interfaces) no matter WHAT kind of programming language you are using, and I don't see Haskell as anything special here.
Let me write the same thing in other words. It is not controversial to say on this list that specifying what is correct means, is a good idea. But for GUIs, in addition to the strong type, you need another relaxed type to hold the values temporarily, until the human manages to deliver correct data, often by trial and error.
In short, we agree, that is indeed *ANOTHER* type. Not only may a FooForm not yet hold information a Foo needs, a FooForm may hold information that a Foo does *not* need. For example, a FooForm might need to hold on to some credentials to prove that it is authorised to create Foo objects, whereas a Foo object might not. In Smalltalk, Java, C#, &c one might look at ways of automatically constructing FooForms from Foo classes + annotations. Using some sort of generic processing, one could also do this in Haskell. Having two classes/types does not have to be twice as much work.