User story and DoD

Is the development of the DSL something that has value to the end-user/customer?

There really isn't much to go on since there's so little detail in your scenario, but the first thing that jumped out at me was the technical nature of the story in question.   Is it sliced vertically (layer, component-based), as opposed to horizontally (something that is customer-facing)?

To be clear, definition of "Done" (DoD) applies to the product Increment, not the Product Backlog item (aka user story).  A Product Backlog item may have acceptance or test criteria which proves completeness when "done", but a Product  Backlog item does not have a definition of "Done" in Scrum.

You should look into emergent architecture, and ensure that you deliver at least one business feature of value alongside the architecture.  Don't build it if you don't need it - and you won't know if you don't deliver some business value.

As Chris states, DoD applies to the increment, not the Product Backlog.

If the DSL is required to make the product DONE you could make a User Story for it, or it may be assumed as part of another story (how much effort/value?). It sounds like, based on your description: "develop a DSL for this application." you may want a user story for it (does it deliver value?), but those user stories are a little different to create when you are developing a dependent object. It could be the Give/When/Then Format. 

Given [my dependent application], when it needs [nature of or rationale of the dependency], then [what you need it to do, why do you need to create the DSL].

I think there are a few other formats for that type of dependency that may even work better. But ultimately, we would probably need more information to give you a more concrete answer. 

I don't agree that the DoD can't apply to the Product Backlog Item (PBI).  

Quoting from the scrum guide directly "When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.".  

If following good INVEST practice where the PBI is independent and adds value in it's own right, the PBI and the increment are one and the same.  High performing teams will be producing many increments per sprint. 

Of course, acceptance criteria is unique to the PBI.  However, an overarching DoD covering more generic expectations applicable to all PBIs, ie, Unit Tests Successful, Acceptance Tests Successful, Deployed to xxx environment etc, is needed to ensure transparency over the real state of items in the sprint backlog as well as giving the team clear guidance over expectations of effort involved when planning the sprint.

The problem of applying a DoD just to the increment (assuming one increment at the end of the sprint) is that it can backload quality assurance to end of the sprint and a create a greatly increased risk of not delivering a shippable increment. 

Is the term “DSL” well known here?

Is it a common language?

Is it the only one user story for the Sprint?

What is its value for customer/end user?

+1 for Steven.