As Gordon suggested above it all depends on the deployment mechanism, but there's a very high chance it'll fail (as it should IMO). Moreso if the deployment is handled within a Transaction that will be rolled back in the event of a failure.
Few deployment systems will go the extra mile to ascertain what functionality is supported by the destination RDBMS and most should follow the rule of 'This is in my code repository, deploy it'. To allow it to do otherwise could introduce breaking changes.
TBH your best bet is to keep two branches of the codeset in your source repository - one with the xVelocity indexes, one without. Either that or deploy first to a Developer instance, then run a script to strip out the Enterprise features you know about then script those changes out to deploy to a downstream SKU.
Yes, that is more work and will require regular code merges with changes, or work creating the downstream code. but it will at least allow you to deploy from a well defined codeset.
If you absolutely must deploy from an Enterprise derived script then you're going to be looking at rolling your own deployment script.
As an aside (and not that it will help you with 2014), as from Sql Server 2016 SP1, Microsoft changed the playing field and allowed 99% of Enterprise functionality in all all SKUs - this includes the CCI's
