Even if it could be done, it wouldn't be advisable and here's why.
A picklist is part of a database object while a custom setting is not. So when you store your records, you can't realistically expect to store values from a picklist that were obtained from a custom setting into fields intended to store picklist values from your object. That would not be advisable from a database design standpoint.
With that said, I fully recognize that picklists are simply strings and their values can change. That's something one can also keep a history on when it happens. But how would you propose to keep a history on changes to a picklist stored in custom settings? I know of no way to do that. You also don't have a way of managing security on a picklist stored in custom settings in the same way you do as one stored with an object. So all in all, I think this would be a poor design practice.
As a final point, if you look at custom settings at the object level in say Eclipse or in your Schema, you'll also see that they show up as a unique object, so you'd be storing picklist values from one object in another object. It might perhaps be a different story if you had a look-up relationship from one object to the other, but that's not what I hear you proposing.
All in all, I think this would not be a good practice to implement in a design.