You're correct that with summed pricing, there is no list of levels, so constructed list building won't work. You also can't just use Perl to fill in a price, because again you don't have level 1, level 2, etc. in the design.
You can put in math with our scripting tags or Perl into the pricing boxes where you set up all the price adjustments. The main downside to this is that the actual value of the price is stored in the data. As an example, I'm programming a survey in English and defaulting to dollars and put feature X at $100. When I make a copy of my survey in Turkish and multiply all the prices by about 5.5 to turn it into Lira (550 lira), there isn't any way for me to undo the 4x multiplication in the raw data. The software will think that my English respondent saw feature X at $100 and my Turkish respondents saw it at $550.
I haven't personally done a project like this, but if you keep everyone together, you probably want to include currency as a segmentation variable so you can include it as a covariate and segment your market simulations and keep your dollars and lira separate. I've heard anecdotally from a few people that seemed to work out alright.