Not that I can think of. There are certain limited things one could do using calculated fields based on the fields you've mentioned, but since [Last Played] is overwritten each time, you have no way of knowing even the next-most-recent play, much less a full history.
I suspect it would be possible, using global variables, to construct an expression integrated into a playlist or view that could build a playback history field, by selectively adding to it each time the code is invoked. That would be a tricky undertaking.
I doubt I would be interested in this myself, but I can certainly see that others might be. It's an interesting idea, and would make a good feature request. It would not be hard to implement, I don't think.
One gotcha would be that as soon as you give someone a history, they tend to want a way to edit the history, and that adds to the complexity of the request. Perhaps if the data were just stored in a normal list field that would suffice.
Also, if the data is just stored as a simple list, instead of actually calculating statistics, then building the views you're asking for would still require sophisticated expressions on the part of the user. And if you say, oh just let the app build all those statistics, then the complexity of the request grows even further.
