If your natural key can only ever be associated with one description, and your lookup table only contains static reference data, then I see no need for a surrogate key.
In the example you gave, your drop down list would contain countries. From my perspective, if the dimensional model is based upon the star-schema then country would not become an independent dimension, but would instead be an attribute on another dimension (such as geography or customer etc). This would not require the surrogate key to be included even if you were to add one and therefore would be a waste of time, effort and storage.
If your dimensional model is based upon the snowflake or your key can be associated with more than one description (for example if the description can change over time) then yes I would include a surrogate key. I would not put this on the reference table though, the surrogate key should belong to the dimension that owns the data.