I finally found the answer on the DD-WRT forums and it's annoyingly simple but I would never have guessed it in a million years.
The username has to be entered in UPPER CASE. So while smb://share@192.168.1.1/public didn't work, smb://SHARE@192.168.1.1/public did!
Just wish I hadn't spent a day trying to get find that out!
If you are familiar with connecting via Linux via /etc/fstab, then you know there are a lot of possibilities of what could go wrong simply because there are SO many different options for connecting to different types of network shares, and it seems like every OS handles these options differently.
I have encountered issues similar to this before, and in my cases, it was always either an issue with ownership/permissions and/or the specific mount point (or a combination of the two):
For instance, I have a ZFS pool setup using FreeNAS, and the mount point is set to //x.x.x.x/share, and the login credentials are supposed to be for a specific user. I have no trouble connecting to it in Windows, but the only way I can connect to it in OS X is to connect directly to the IP using the root credentials. I know there is a way to fix it, but I haven't gotten around to looking into it yet.
So my first advice would be to try connecting directly to smb://x.x.x.x or smb://x.x.x.x/share, or any other variations that you can think of, using various sets of credentials that have access to that box.
It could also be a Samba version issue (which Samba is notorious for) that could be causing these 2 guys to not agree with each other.
Also, sometimes in OS X if I am trying to mount a share with one of the various mount commands in Terminal, I find that it tends to give me trouble sometimes if mounting with my normal user, so in certain circumstances, I need to use sudo in order to mount it as root.
If all else fails, I would try installing the Netatalk packages on your Raspberry Pi. Netatalk is an open source version of the Apple Filesharing Protocol (AFP), which OS X obviously tends to handle much better than Samba (SMB). If you enable the share to also use AFP, you can connect to it from Finder using afp://x.x.x.x/share, etc.
If you are running Raspbian, those packages should be available via apt-get. I hope this helps!
Best Answer
I had the same issue with my Netgear Nighthawk R8500 until I reduced the router's password to 14 characters, as suggested by user137327. Since the router's password is also used as the Samba password, perhaps the cause is related to the legacy of Samba and Lanman password limitations:
"passwords are limited to a maximum of only 14 characters"
"Many legacy third party CIFS implementations have taken considerable time to add support for the stronger protocols that Microsoft has created to replace LM hashing because the open source communities supporting these libraries first had to reverse engineer the newer protocols—Samba took 5 years to add NTLMv2 support"