You'll never get around the source of the problem, which is that it's not the priority of the artist to figure out how to name and organize things. It's the same as bothering developers to "update the wiki". Pick a convention and structure the culture around that by providing a spreadsheet of assets or an equivalent document. Maybe the artists "own" their assets, so you lead with their username. Maybe you're building the environments collaboratively, so you lead with the environment first. Maybe you envision the project being a long-term thing like an MMO, so you start with the year and month. These are things that a good producer will keep their eye on, because they reflect how the team is communicating.

The most important thing, from the technical standpoint, is that your asset pipeline is robust and can handle weird things. The engine shouldn't consume files haphazardly, it should deal with "built" assets, where you can trace things from the in-game content back to the source file. A configuration layer usually appears to give an in-engine ID to a loaded asset, because files and assets do not map 1-to-1. You can choose to fight the organization battle in that layer, rather than in the file system. When you have a slick IDE like Unity, this is all built into the GUI, but a custom engine can just use a batch process to do the same.

Version control is useful - not a DVCS, because it doesn't scale to binary assets, but SVN or Perforce. Artists will groan about waiting around for the VCS to resolve things and the inevitable problems with locking, renaming, and deleting stuff, but their lives will be better off overall if it's in their workflow loop. It's "10 hours waiting on SVN Updates" vs "30 hours debugging project history".

Here's an article on "import" vs "export" based pipelines, where the thing being "imported" to the engine is a common, standardized format that every tool can export - rather than one proprietary tool the team happens to use:

http://people.cs.aau.dk/~bt/GameProgrammingE09/Pipeline.pdf