No, that's not really what AOP is for. AOP is not for implementing interfaces at runtime but for composing systems: business logic may be defined in one place for example and logging logic in another and an AOP framework will then compose the two into a bigger system. AOP is designed to cover what it refers to as cross-cutting concerns, that is functionality that is required by many objects within a system but which is not core to the concerns of those objects.
AOP works by intercepting calls to methods on objects and performing some action in addition to, or instead of, the actions performed by the intercepted method. The interception points are known as pointcuts and the intercepted method is the advised method, with the code being advised on the intercepted method being known as the advice.
I am only familiar with AOP via Spring.Net's AOP Framework which allows you to specify and apply pointcuts and advices both via configuration files and programmatically. Spring.Net AOP has four types of advice: before, after, around and throws which are invoked on interception of an advised method before the advised method is invoked, after it is invoked, both before and after its invocation and when an exception is thrown respectively. Whether applied via configuration or programmatically, the advised method has no knowledge of Spring.Net AOP or even that it has been advised. The advised method must however have some kind of implementation to intercept so your example would not work.
The Spring.Net documentation is very readable and is very good at explaining AOP in general and Spring.Net's implementation of AOP in particular and contains many examples. It is well worth a look even if just to understand AOP a bit better.