Both out of the box and directly it is not possible.
Not out of the box: you can write your own BindingExtension that would behave like that: bind if the prop exists, else ignore. You can also, khem, turn off reporting binding error, but of course that is usually not wanted.
Not directly: you can create an attached attribute of some type, and then set such attribute instead of setting the binding. Your attribute-setter would attach to datacontext-changes and inspect the objects and visual components as they fly around and set the binding or not.
Not directly#2: You can try to "hierarchize" the styles and triggers. As you know, Trigger has a Condition. Split your style in two parts: first is the common style that does not need to be "guarded", and the second one contains features dependent on having "Blargh" property. Set the first style as default/normal. Now create a readonly attached property called "DefinesBlargh" or "HasBlarghDefines" that checks if the target object's datacontext actually has such property. Now add to the first style a trigger that detects whether the styled control has "HasBlarghDefined" equal "true", and in the trigger's action...
...and here's the problem. What to do there? You cannot replace the style again to the second part of the style, as it probably would remove the trigger and in turn deactivate the logic (it would be one-shot). Or, it may simply crash due to the fact of trying to change the style two times in one update sweep. I actually not know what would happend, but I sense "a smell". More over, changing to the second-part would simply erase the common things that the first part set up.
So, if it actually would run and replace the style, you'd have to ENSURE that the original trigger logic and rest of the first style is preserved, I'd suggest using "style inheritace", that is, the based-on style property: http://wpftutorial.net/StyleInheritance.html That is, do not create two separate parts, but rather, make a "base part" with all common things, and a "specialized part" that is based on the first and adds the unsafe extra things. Now dynamically re-replacing to the specialized counterpart is a bit more reasonable.
Or, if you have some control over the layout, you can get smart: Why apply the two styles to the same component? Set the general style on some outer bound of the control and place the extra trigger there, and let the trigger apply the small unsafe second style to the control.
If you really have to target exactly one control with both parts of the style and cannot use "based on" or maybe if it simply does not work etc, you can do another smart trick: use a MultiStyle
that allows you to define a style that mergers two/three/+ other styles into one, and then build a trigger hierarchy as follows:
multitrigger
condition: HasBlarghDefined = TRUE
condition: your own data condition
setter: set style = multistyle of "generalpart" and "usnafepart"
multitrigger
condition: HasBlarghDefined = FALSE
condition: your own data condition
setter: set style = just a generalpart
IMHO, that just have to work.
edit: forgot to past the critical link: The MultiStyle