One way that you could do this, though whether it is neater is open for debate, would be to build a Reporting Services Data Processing Extension - they are not hard to do, and the one I propose is really simple...
To make it work for anything where you have a fixed list, and I am just throwing an idea out, you could create a "query language" that looked something like this:
ParameterType=.net type&DataColumnName=Whatever the user wants&Value=first value&Value=second value...
That way inside the extension you split on & (you would define a rule to escape & in Value entries so \& or something) and then check you have just one ParameterType and DataColumnName entry (if ParameterType doesn't exist default to "System.String" and default to "Value" or something if DataColumnName doesn't exist - throw an error if they are multiply defined) and for the former, if set, use a Type.GetType to set the column type and the later set the name in the "schema" for the result set.
Finally all you'd have to do then is loop through all the Value entries and add a row to the result set.
This would work not just for multi-valued parameters but for anything that you have a fixed list of that you want to turn into a data set and means no trips to databases or anything - the processing would happen on the Rerporting Services server.
In the case of the multi-valued parameter you'd just do a for loop in the query in the report to generate the query.
Maybe, in the quest for neatness, you could also create a handy function that takes a parameter as an argument and generates the query so you have a shared library and a data processing extension and all the person that creates the report would need to do is something like (that would be a five liner function I think):
=MultiValueQuery.GenerateQuery(Parameters!MyMultiValueParameter)
Neat, maybe, you be the judge!