You could use a tab control with a cleared theme style, background set to transparent and no border (basically an invisible tab panel or just cover the entire tab panel with the portals) containing two different versions of the portal, one with the field and one without it.
On each individual tab be sure to set two unique laout object names (not the tab names) and then set up a script that will use Go To Object[Name] to switch the tabs to Portal #2's tab once the criteria is met.
To ensure that end users can't accidentally switch the tabs by clicking on that seemingly empty spot on the layout above the portal, you set the tab control fixed width of 0px and a tab justification of left. This also hides the tab lables if you happen to have them.
For a cleaner experiance you can set the script to go to the same portal row and the next field in portal #2 as you were in portal #1 when the script is changing the tabs. Also, depending on how your portals and layouts function, you might want to store a global field or variable with the last state of the tab control and portal row / field so it can be instantly restored should something happen like a script taking you to another layout for a few seconds and then bringing you back, which would normally reset everything and break the illusion.
I use a concept somewhat similar to this to hide / show a facebook notifications-like dropdown containing a portal with notifications on our company's system, but you would be "swapping" portals in this case.
Ray Cologon has a good section on Using Dynamic Screen Elements including portal invisibility and concealed tabs in the fileMaker Pro 10 Bible.
If the control field -- the one which deteremines whether or not entry into the other field is allowed -- can be used as part of a mutli-key relationship, you could make the field you are controlling be shown only via that relationship. Thus if the value is valid (whatever that may be), the relationship exists and the other field appears, or, if not valid, the field simply isn't there.
One method is to have a special foreign key field which is triggered to auto-enter viat the evaluate function based on the content of the control field. If valid, the foreign key gets set which validates the relationship, and the realted field appears. Until then, then controlled field simply doesn't exist because there is no "related" record.
This has been around for years as the Disappearing Portal/Field Trick, and you can find it in some archived discussions and in some third-party FM how-to books going back almost a decade. Sorry, I don't recall who to credit it to, but it was an eye-opener to me when I first saw it used.