You could try cross compiling snmpd to figure out the problem.
When I started using dd-wrt, my cron jobs would work unreliably. Turns out dd-wrt had a long standing known cron falling asleep bug. I followed a simple tutorial like this and quickly got a hello world working. Then got dd-wrt's cron code from subversion and it compiled easily (static link). Just killed cron from dd-wrt and ran my cron with added debug messages. Found a small bug in dd-wrt specific cron code, proposed a fix and BS submitted it and dd-wrt users enjoy reliable cron jobs ever since.
Since snmpd is a pretty standalone process, the same technique could work to solve this snmpd bug. Alternatively contact egc about building a full build but that's more complicated.
I finally solved my problems, I thought I might summarize here what I did for anyone stumbling over this thread having the same problems. It turned out to have a dead simple solution. There are some OIDs that make snmpd crash and burn when asked for. It seems those OIDs aren't asked for when Munin does it's normal probe though so they aren't a problem in day-to-day running, only when doing the first setup (which seems to do a scan of all OIDs).
So the thing you need to do is following the guide on https://wiki.dd-wrt.com/wiki/index.php/Munin but with the addition of actually restarting snmpd after having run munin-node-configure. This can be done either by clicking Apply Settings on the services page of the web gui or by telnetting/ssh:ing to the router and running "snmpd -c /var/snmp/snmpd.conf". It might also be a good idea to first check if it really has crashed by running something like "ps|grep snmp" (which should output two rows if snmp is running).
Oh, and another note about the wiki guide: It really isn't a good idea using "public" as community name. Put something else in there, just be sure to put the same thing in the RO Community setting in dd-wrt and in Munins env.community setting.