I very much doubt that this idea can work in "the real world". There are a couple of reasons for it,
DSLs have been used with great success for over a decade by the Functional Programming community. If you look into this a bit, bear in mind that they often use the term "combinator library" when referring to DSLs. The FP community's favourite use of Monads is for DSLs (a successor to Monads is proposed - Arrows). Also note the arguments in favour of Domain Specific Embedded Languages (DSELs) over DSLs.
The Logical Programming community gets DSLs, too. See this paper:
"A Horn Logic Denotational Framework for Specification, Implementation, and Verification of Domain Specific Languages" by Gopal Gupta and Enrico Pontelli
(www.cs.nmsu.edu/~gupta/logden/dsl.ps)
Imperative programming language practice has lagged badly, and it is time to enjoy the benefits of DSLs/DSELs.
The domain is only understood during the construction process. This is a very common problem in a lot of projects. "Analysts" don't know enough about what the system formally requires and are not able to communicate requirements in a concise way. I would assume this is a prerequisite for developing a domain specific language.
You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative.
Domains are too broad. A lot of projects deal with a domain like "the business of United Airlines". This is essentially not a single domain but at least a dozen formal business domains and even more technical domains. One ends up with dozens of languages, potentially with different syntax and editing tools.
For a look at an approach for linking domain semantics for very complex endeavours, see the work for the Rosetta System Level Design Language (www.sldl.org).
Domain is insufficient. You can see this with fabrique at the moment. Nice to quickly put together simple web apps. But as soon as you work with multiple databases and a message queue and a couple of flat files at the same time as your data source and sinks, you need more flexible, more mature tools
It would be wrong to judge DSLs by where fabrique is at right at this moment in the development of their product. There is plenty of other experience with DSLs.
Graphical editors break down early. This is even true for database modelling, where only very sophisticated (and expensive) tools give good graphic representation for the entire development circle. And this is only data modelling.
Agreed, but there is no particular connection between graphical editors and DSLs. Historically, DSLs have been developed non-graphically.
Redundant learning. Learning a new domain language is only justified if it gives you very significant advantage about the generic language. With languages like Java and .NET this is not easy.
You are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.
Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge.