I recently discovered, after trying to change Safari's icon, that Apple's apps in Snow Leopard have read-only permissions enabled for all users except root:wheel. This eliminates users' ability to use copy-paste replacement icons in the Get Info panel.

As a workaround I quit the Finder, and relaunched it as root in Terminal:

sudo /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder

I was then able to paste a replacement icon into Safari's Get Info panel. Then, after relaunching the Dock, my icon appeared.

[robg adds: You can quit the Finder using Activity Monitor and it won't restart. If you try this hint, remember to again quit the Finder and relaunch it as your normal user once you're done. I haven't tested this one, so I can't say if it breaks code signing or not.]

Note that if this breaks Code Signing, then applications might no longer be allowed to access the keychain, will no longer be permanently allowed an exception in the firewall if the application checks its own integrity (known to have caused trouble for configd, mDNSResponder and racoon), or might cause trouble when using software update.

More speculation here, but if the Finder should somehow have to recreate its preferences or a cache file or create any other file while it is running as a super user, it'll no longer be able to change/delete or possibly even read those files the next time it starts as your user. I'd use this hint with caution, and a willingness to use the Terminal to patch things up (possibly from another administrator account) if they break.

chown-ing apps so that your user actually owns them worked when I was testing out some things a while backů┬áDon't know if that is more or less likely to break code signing, or if it works in this specific case (changing icons - I was messing with something else in the package), but it may be another solution.

Earlier I wrote "Quick tests changing the icon for iTunes, Safari and Activity Monitor show no problems with Code Signing". True: just pasting a new main icon using Finder's Get Info does not seem to break anything.

However, actually changing program resources (so, not just the application's main icon for Finder, but all icons an application uses) using third-party tools MIGHT break the signatures. Now, I don't know if that is a problem or not. Apparently, CandyBar (at least the old versions) breaks the signatures, but no problems seem to have been reported. Up till recently, MacUpdate showed a very old comment (dated January 10th 2008), from one of its developers:

As for changing your application icons by hand, you are more than welcome to do so! As a warning: if Apple enables the built-in code signing in a future Mac OS X minor update, your applications will simply no longer launch. This is what we're trying to safely avoid by disabling that feature until we get a sense from Apple of their plans.

This comment has now been removed, so I assume that Panic investigated (or even stalked Apple to get an answer) and did not find any problems either. I have not tested the new release of CandyBar to see if it still breaks the code signing. After installing any third-party tool, one can test using:

Maybe warnings like "a sealed resource is missing or invalid" are not as bad as "code or signature modified"?

As a side note: Ars Technica suggests that the code signing might (only?) have been introduced for the iPhone (in which applications might indeed not run or even install if the code signature is broken):

And let's not forget the "Mac OS X" technologies that we later learned were developed for the iPhone and just happened to be announced for the Mac first (because the iPhone was still a secret), like Core Animation and code signing.