As of two years ago (I haven't looked at this issue more recently) this was possible only in part and only with lot of code.
Every material consists of a number of properties and a number of Assets. When creating a copy of a material definition the standard code will simply copy the reference to those assets over, meaning that if you change the asset in one material later, it will automatically also change the asset in the copied material. This is also the way it works with the GUI.
To make a full copy of a mateial you therefore also need to make copies of each asset. That's a lot of properties to copy and some of them can get impressively big, Not to mentioned contain nested assets (which also have to be copied).
There was (at least this was an issue two ears ago) also the problem that not all assets were fully exposed in the API. Certain material settings could not be set from the API, nor could they be copied to a new material definition. This was in the appearance asset, so things like assigning new bitmaps to a mateial definition) could not be done. If you only try to alter the base colour and not the render appearance you should be fine regardless. It may also be that this asset has since been exposed to the API and this is no longer an issue.
Writing your own copy method for each asset class may still be required (though I think this has been made less awkward in the revit 2016 API)
(There was a work around for this problem but that was pretty elaborate as it required calling into unmanaged code and the use of C++/CLI to access external C++ libraries)