Can you give an example of your "obtuse and challenging text"?
You enter criteria into portal fields just like you would for fields that are local to the current layout record. The results of the find, though, can confuse people if they don't think through what they are specifying. If I enter "Apple" in a portal field, I am telling FileMaker to find all Layout records with at least one related portal record that has "Apple" in that field. Once the find is performed, however, those layout records located by the find show all related records in their portal--not just the related records that had "Apple" in them.
This is how FileMaker is designed to work. If you only want to see the matching portal records in the portals, you have to use a different approach, but I'm just guessing here as to what the issue here is with your finds.
A user would have to pull up a duplicated window of the db, switch to the Characteristics table, and manually copy something that looked like two airport codes mashed together*, with an "A" or a "Z" prefacing the code. Since the total characteristics entries are lengthy (in record number plus character length), and they don't paralell simple words with vowels, they're a little challenging to memorize, let alone use without a duplicated window of the Characteristics table next to the find request window.
At this point, I'm still looking for a pop-up menu to populate a find request.
* - If you're curious, this was a database to study timely occurances of natural phenomenon where speed of entry in the field became more important than doing a more proper different-components type of recording. Multiple incidents were joined since the study was more about groups of dynamics and subtle variations than absolute properties.
Yes, but that example applies whether or not you use a portal. It's a case of understanding how to use FileMaker Find operators rather than any features associated with portals.
I don't have any idea exactly what "something that looked like two airport codes mashed together*, with an "A" or a "Z" prefacing the code" looks like--you haven't been specific, but this can be scripted off a drop down.
Example: value list has the values Apple, Orange, and Cucumber.
After the user selects Apple, you want to perform a search for *Apple*. (many other possibilities here, just modify the following script to accomodate what you need.)
Make the drop down list point to a field with global storage specified so that the script can get to that value while in Find Mode.
Enter Find Mode
Set Field [YourTable::yourField ; "*" & YourTable::gDropDownField & "*" ]
Set Error capture [on]
Perform Find 
Edit Note: Left out "YourTable::" in the second parameter of the Set Field step.
My original post encompasses the central question. I'm looking to feed non-typed-out values into a portal field, while in Find-Mode to speed up user entry before searching. I preferably am hunting for a means to have a pop-up (saturated with values from the foreign table; Characteristics), drive a remote portal field.
The codes of the Characteristics table are turning into a red herring for you. They will always be textfield values nobody wants to type out in a portal window/field. Nor can I improve their current use. I'm simply looking for some sort of automation in allowing a searcher to "drive" a find operation without a duplicated window visible and do a manual lookup on code that looks like A>CLP.STR.GLL, but tend to become long.
The second line of your script is not usable. It complains about "an operator is needed here," while highlighting the latter portion of the line:
; "*" & gDropDownField & "*"
where gDropDownField is replaced with a correct field.
Was this for a non-portal'ed record?
This script will work for both fields that are part of the layout's table and also for criteria entered into a portal record. The error you are encountering indicates that you haven't used the correct buttons to specify the parameters of the Set Field step.
With Set Field added to your script and highlighted in the script editor, you have two specify... button in the lower right corner of your script editor. you will need to use both to create this script step.
Click the upper button and select the target field for this step. (YourTable::yourField)
Click the lower button and enter/select the expression you want to use for the expression to the right of the semi colon (;). In your case, it sounds like you can just use YourTable::gDropDownField as the second parameter. Do not try to enter the semi colon. That will be displayed after you have used both buttons to properly set up this script step.