Market, maybe. Community, YES! If you can pull better numbers per joule and come in cheaper on hardware cost vs gpu, people will eat em up!
This part (cheaper than GPU's for a given hash rate) is unlikely. When it comes to scrypt(1024,1,1), a modern Radeon GPU (prior to the 7xxx series, anyway) very nearly is an ASIC already optimized for scrypt, and designed at optimal process node and with economies of scale of being a consumer product. I've already given it a go with the Xilinx Artix-7 FPGA's surrounded by large quantities of DDR3 and tried a variety of approaches across the TMTO spectrum for the known methods of calculating scrypt, ranging from no use of external memory at all and pipelining the entire calculation, to replicating the way cgminer does it in OpenCL (with various lookup gaps). In the end, the best use of the prototype hardware was actually to mine the heck out of Yacoin, since scrypt+chacha20/8+keccak(N,1,1) with N=32 (as it currently is for Yacoin until tomorrow) was almost trivial to optimize for FPGA's:
https://bitcointalksearch.org/topic/m.2127307
For the probable FPGA vs. GPU cost relationship to change, someone needs to find and disclose a method of further shortcutting the already-known TMTO of scrypt(1024,1,1). And at that point, whatever that optimization happens to be, is very likely going to be equally applicable to OpenCL to speed up GPU processing of scrypt too.
What I have yet to see is either the BlockBurner team or jasinlee say "Oh yeah, we're genius cryptanalysts and found ways that scrypt(1024,1,1) can be calculated much faster and/or with significantly less logic than anyone else has figured out how to."
What is the frequency and total data bits width of your DDR3 used?