Since you can't do it, I'd suggest storing the values in a table and using the specify field option in manage | Value lists... to pull the values from a table rather than custom values. Since your values are now in a table, they can be exported.
Since your users probably want to edit the values, you'll need to replace the "edit" option in the value list with an edit button on the layout that takes the user to a table or list view layout that presents them with their values for editing.
If you have a lot of file copies with custom values that you want to move into tables, you can try using the design function ValueListItems ( get ( filename ) ; "Yourvaluelistname" ) to extract the values and enter them into records in a table.
If I create another table then each value in the value list becomes a separate field, then I have to list each field on my form. That takes up a lot of space. I liked the value list because of its compact size. It seems to me I would go from a compact value list to a space hungry list of check boxes? Am I missing something here?
I'm thinking the way to go is to "Use value list from another file" and manage all the value list items in separate files. The values are not going to change as I alter the generic database, only the generic database itself.
Whether you store the values in a different file or the same file, you still can't export the values easily unless they are stored as values in a separate table. The values can be stored in one of two formats and you'll get identical appearance when you use the value list:
One field in one records stores all the values separated by carriage returns. You can set this up simply by copying the custom values and pasting them into a text field.
One value/record in the specified field of the table. This takes a little more work to set up, but is much more flexible in how you can manage the values.
You don't have to list any of these values on your form--nor would you want to. To allow users to edit the values, simply create a separate layout that refers to your table of values. You can set this layout up as a table or a list view layout. Users would click a button to bring up this layoout to edit values and then click a button to dismiss it. Using New Window, you can even pop it up as a floating window very similar to the dialog you see when you select "Edit" to edit custom values.
"The values are not going to change as I alter the generic database, only the generic database itself. "
If the values aren't going to change, then you don't need anything but custom values. If you plan to allow users to edit the values and you have multiple copies of your database in use by different clients--as described in your original post, then managing your value lists becomes an issue you have to deal with. Placing the values in a table, makes them easy to work with for you and your users. I can see how you can get it to work as you describe, but it seems to me this will harder--not easier to manage than using the separate table approach.