So before the explanation you could configure a separate OSPF area (or possibly the second ospf process) that is purely for the DMVPN, that way the hub is the DR for that OSPF instance, you can initially make the cost higher to go over the DMVPN than adjust the cost when you're ready to cutover.
Another solution could be to run EIGRP over the DMVPN instead since it's all Cisco equipment you don't really have to worry about interoperability, but seeing how you already run OSPF in your LAN you're probably much more comfortable and experienced with it.
The only other option (I'm aware of at least) would be to a dual hub topology which may break some things since you you already have L2L tunnels to each site on one of the hubs, I've never had to attempt to configure this in tandem though so I'm unsure what the result would be. You may want to do this after the fact though anyways in order to have some redundancy should the DR go down.
The reason that this needs to be configured this way is because the hub is what creates the NHRP mappings in between all the sites, with the nhrp multicast map each site sends it's updates to the hub and the hub then forwards it onto all the other spokes. The spokes learn of the routes in the NHRP 'cloud' but since the DR isn't part of that topology it has no way of sending updates through NHRP since the BDR doesn't send out updates until it becomes the DR, with no way to forward the updates there is no way to propagate the information needed for the spoke-to-spoke tunnels. Furthermore the spoke routers cannot form an adjacency with the DR making it since as defined in the RFC 2328 'On broadcast and NBMA networks, all routers become adjacent to both the designated router and the backup designated router' Reference Sec. 10.4
Let me know if this helps or if you have any more questions!