This is a very abstract customization problem. Flexibility creates complexity. I don't think there's going to be an elegant solution that will meet all the boundary cases.
Having said that, can you use domain knowledge to narrow scope? i.e. who is the form builder for?
- Are you building this as a general tool? In which case, we can't predict how deep a form will be.
- Is this for a specific domain? Perhaps this will allow you to create templates. Maybe it'll restrict the question-types. If you foresee a 100-level deep branch, maybe a form isn't even the right interaction. Or questions as a unit is too granular and you should be looking at this at page-level.
Re: tree vs. conditional-logic.
You would need a condition wizard regardless of tree or form view: When you're adding a new node to the tree, you would need to know if you need to branch. When you add a new field to the form, you need to know if it has subsequent questions. (Although the example of the condition wizard that you provided isn't very good. It's too systematic/technical for the general user.)
I'm partial to the tree. It clearly communicates the decision points. It's harder to communicate that logic in a form. Although I would go with a visual tree rather than a text tree:
I would not fixate so much on it not looking like you're creating a form. You're really performing two actions: (1) Creating the interface--the form, (2) Creating the behaviour--the conditions. It's hard to mash the two together because the behaviour requires the user to interact with a form that doesn't yet exist. How can you show something that doesn't exist yet?
In the diagram that I provided, the user is seeing the behaviour. When he clicks on "Add a field", the system would launch a dialog that initiates task (1). This is the condition wizard that I didn't mock up.
The drawback of the visual tree is breadth (limited by horizontal real-estate). Whether or not this is the right approach, again, will depend on the context of the form builder.