As others have pointed out already, the AVR is a "harvard" architecture. This means, it is not possible to fetch instructions from the (separate) data bus.
However, there are (humble) ways around this problem.
1) There exist (a few) AVR parts with a pseudo van-Neumann architecture. This means, the instruction and data busses are connected to the same memory, effectively enabling the part to fetch instructions from data memory. The AT94 FPSLIC parts are an example of this rare class of AVRs.
2) If your code is changed very infrequently, you can use the "self programming" feature that some of the newer AVRs provide. It's possible to load code from an external source, write it to the instruction flash and then execute it. There is a (quite low) limit on how often you can do this, so it really depends on your application if this method is useful to you.
3) While you can't fetch AVR instructions from the data bus, you can read data from it (obviously). There's no limit on how to process this data, and in fact you can interpret the data (in software) as if it were instructions. This effectively allows you to implement a virtual micro that executes virtual code from the data bus. The "basic stamp" products do this with a proprietary basic interpreter. The Dunfield "C-flea" is a cheap 16-bit development suite that includes a C compiler and virtual machine (he's got one for AVR).
4) Just like the interpreter approach in 3), you can also opt to emulate an existing microcontroller. This will give you good toolchain support. I found the MSP430 architecture is very comfortly to emulate. In fact I once made a working tiny mixed hardware/software implementation, that emulates MSP430 on FPSLIC at a 1/6 clock speed (6 AVR cycles imlement 1 MSP430 cycle).
All of this is possible. However, if you're in an early planning phase of your project, you're certainly better off choosing another architecture for your project. Running into your limits before even having started is not a good sign.