Sure you don't know all possible objects (forms) to be created but maybe there are many common business processes as "Claim", "Order", "OrderPosition", "Shipment", "Physical Unit", "Contract", "Partner", "Customer", "Contact", "Customer Group", "Location", "Address". You could define some (as much as possible 😉 ) common objects with their common fields and some additional fields in different types. The rest of the fields within the EAV typed tables. Categorical avoid one description table with a huge text field to store any data type. Use typed attribute tables like EAV_DateTime, EAV_References (indexed varchar field), EAV_AnyText (non indexed), EAV_HugeText (varchar(max)), EAV_NaturalNuber, EAV_FloatingNumber, EAV_Blob, ... .
The approach to store your forms as XML is a good approach in my opinion! Maybe use two XML columns. One for the form designer XML and one for the data mapping. So one contains the graph XML which defines the form and one which maps the fields of the form to one or more tables (objects) within your database.