You can configure multicast between spokes with command ip nhrp map multicast <remote-spoke-outside-ip (nbma)>.
As @Steven wrote, it's not practical for a several of reasons.
For a full-mesh design, you need to static configure this command on every spoke, and one of the advantage with dmvpn and nhrp is that spoke can have dynamic ip address on the wan interface. So with "map multicast"-command you need to update all spokes everytime a spoke changes an IP address.
With a fulll-mesh spoke-to-spoke design with active ipsec tunnels between all spokes could be an hardware issue (depending of how many spokes etc...) So to be sure for that to work you might have high-end hardware on all spoke sites.
Thank you for this info! What I am rying to understand is "why" it is not possible, since the encapsulation is the same (spoke-hub or spoke-spoke). So I´d wonder to understand in details the reason why the traffic should go through the Hub.
have a look on the link above
As everyone is described that some important notes and I want to add some summary of all as:
1. If Spoke to Spoke multicast configured then you need static IP on the Spoke which is against the advantage of DMVPN.
2. There is a chance to connect full mesh VPN immediately due to Multicast and it will overhead on the all Spokes because spoke routers are lower devices.
3. Multicast replication may create an issue for you etc.
As you want to know why is it not recommended then my opinion is below:
1. Multicast MAP in full mesh will be required manual configuration on each spoke and hub.
2. Spoke to Spoke VPN will auto UP and it may cause high resource uses.
3. Routing Protocol update may use spoke to spoke connection means high resources uses ion the spoke router.
4. DMVPN giving function to work with a dynamic IP address on Spokes but you may lose this function or every time admin headache will increase to update on all routers.