So wait, they have network accounts but are not bound? So I take it they log in locally and then log into servers with their OD account?

How about making an alias of the network share for each user with password in the keychain and adding it to the user as a Login Item?

Well, having network accounts or OD accounts would be best, but if you really don't plan on using them, then "security" from Terminal will be your friend in this case.

I was able to get the following general syntax to work in my tests with an AFP share, though YMMV. It will at least get you going in the right direction-

security add-internet-password -l ServerName -a <username> -w <password> -D "network password" -r "afp " -s <ip.add.re.ss> -T /System/Library/CoreServices/NetAuthAg

ent.app/Contents/MacOS/NetAuthSysAgent

Replace the relevant bits with your specific information. Also note that there is a space after the afp, as in "afp " (it needs to be a 4 character string)
The "ServerName" is just the label so use whatever you want, otherwise it just uses the ip address you specify.
This of course all requires knowing your users passwords, if you planned on having it work silently. I'm thinking if you left the password out, they would be prompted on first run and they could enter it and save to the keychain, but that doesn't seem to be what you're looking to do.
I have not thoroughly tested this, and there may be some missing elements in your specific case to make it actually work, so read the security man page-

man security

There's a lot of good stuff in there.
Also, this adds an entry into the current user's login.keychain, unless otherwise specified, Since Casper scripts run as root by default, you will likely need to modify any script to direct the command to the logged in user's keychain instead.

The next piece would be getting the auto mount to happen, but that's another story.

Jared, correct. Honestly this is a temporary solution. Most of our files/services are cloud-based. The files on our internal network are old files that haven't been moved yet, so they won't need to access this for long.

mm2270, I think that's exactly what I needed so thank you so much! Once that's done, the auto mount shouldn't be too difficult I don't think but we'll see. Thanks again for the help!

mm2270, again thanks. This was perfect. I still have to test pushing it out through policy but it works. BTW auto-mounting is super easy since all my machines are 10.7.x, I just use Configuration Profiles under Login Items -> Network Mounts.

@jwelsh - You're welcome. It was a good exercise for me, since although I've used the 'security' command before for different purposes, I'd never actually added a server password entry before.

Just remember that pushing via script/policy, you'll want to make sure it directs the new keychain entry to the current logged in user's keychain, or it may try to add it to the "root" account keychain. I think all you need to do is add the path to the users keychain at the end of the command, like "/Users/username/Library/Keychains/login.keychain" but I haven't tested that.

FYI if you're sending this out via script/policy for the sake of adding a keychain item to a user's keychain and you're getting an error of "The authorization was denied since no user interaction was possible" you also need to run the following command before mm2270's syntax.

security unlock-keychain -p USERPASSWORD /Users/username/Library/Keychains/login.keychain

(or whatever the path to the user's keychain is)